Software development of the 90s was defined by plan-driven processes.
Later, there was a shift from a predictive mode of planning to an adaptive model.
So said Martin Fowler, software consultant at ThoughtWorks, at the Agile Africa Conference, in Braamfontein, this week
The process-driven approach separates planning and the execution of those plans, noted Fowler. In this approach, success was defined by how closely the execution adhered to the plan, he said, adding that the problem with this strategy is that requirements are often unstable and it is common for things to change.
"The Agile crew broke that dependency on the plan and encouraged people to shift things around. Agile is about embracing change. Saying something went according to plan is meaningless in an Agile approach, because the plan changes so frequently."
The idea of creating standardised processes is an incorrect approach to software development. "Only when everyone has the same personality will standard processes be successful. Business must be thinking about people first, then processes."
Software design value
Only by actually building the software do you realise how to make it better, he said. However, he stressed that this is no excuse for poor design. According to Fowler, the problem with bad software design is that trading quality for cost often ends in less favourable results. "The argument for good quality design is, and must always be, an economic one," he said.
"Customers and users are often none the wiser when it comes to poor quality internal functionality of the software," said Fowler. Businesses and customers frequently choose the cheaper option with the poor design to save a buck, and in doing so, are aligning themselves with problematic software without even realising it.
By focusing on speedily releasing the software and making short-term sacrifices with the idea of fixing them later, engineers are deliberately being reckless about software development, he said. "If you trade off attention to design to try to go faster, you actually are going to have crappy code and go slower at the same time," he concluded.
"We are still going to be able to go faster if we create quality code. The thing about software is that you don't really know how to make good software until you've made a mess of it first."
Share