InfoQ, one of my favorite sites on software, recently posted an article Key Takeaway Points and Lessons Learned from QCon London 2012. If you missed the conference but are still interested in recent trends of software development, it’s definitely a great read.
I browsed through the article, and found several interesting points there including the comments on Spring framework that VMware bought in 2009. In the following, I just list a few interesting or surprising comments and tweets from the article. If you are interested who made the comments based on which session, just check the original article.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
“If something is painful, you should do it more often and eventually the pain will go away, thus making deployment a non-event.”
“The core problem is that developers like solving problem that nobody has.”
“Too much abstraction and solving problems nobody has plague software development.”
“If you hired a dev and he told you that to build your blog he needs #NHibernate and #Spring, what would you say?”
“Spring, once the antidote to EJB, is now a byword for complexity here.”
“Another example is enterprise Java. Enterprise Java Beans and J2EE were the fix, and then the problem, for scalable distributed applications. Rod Johnson came up with Spring, the lightweight alternative. Now I am hearing how Spring has become bloated and complicated and developers are looking for lightweight alternatives.”
“Simplicity is a choice. No tool will do it for us – testing tools don’t care if it’s simple or not.”
“‘every decision is a trade-off’ or ‘there are no best practices'”
“The main idea was to use example of the team both speakers worked with in past 4 years to show how being agile, focused on good process and delivery can lead to “delivery zombies” – teams that only focus on delivering stories without asking how? and why?”
“If you think experienced people are expensive, you should see how much inexperienced people cost.”
“Admin mistakes most common source of system failure, not hardware faults. 2nd culprit – clusters.”
“Functionality is an asset, code is a liability.”
“You can’t tune something you don’t understand.”
“Understanding how someone is going to use your code is very important when developing a public API, you can’t just expect them to know everything you know.”
“Don’t use patterns for the look of it.”
“Never stop thinking, and never stop questioning why you’re doing something – especially when somebody else tells you to do it. Good programmers follow these principles, but better programmers always understand and remember their cost.”