Some thoughts of a Machine Learning Practitioner on Software Development, Management, Team Building, Startups, Python, Agile Development, Data visualization... that will distract you from your end goals by making you less efficient but are critical to manage in order to succeed. Don't forget that long time adaptation to inefficient approaches can become your enemy. Let's try to empower others by sharing knowledge & personal experiences.
Sunday, March 15, 2009
Greedy agile, waterfall and local minima
Everyone in the agile world can't contain their words about waterfall inadaptation to real world software projects. I have to admit, I am a fan of XP, scrum and most of agile approaches in general but I feel that people are loosing the big picture provided by the waterfall framework. Agile is kind of a greedy approach that lead you to local minimum where you are stuck too often. I would like to see someone creating value and velocity cost trade off of short term decisions. Those decisions are ofter push through agile methodology without questioning. Currently, at pivotalpayments, we are stuck in a huge local minimum created by such an approach and it will take such an effort to get out of it. The velocity created by a design choice taken long time ago was emazing at firt but it is slowing us doing now so much now. A major refactoring is required and we will stop development for some iterations. At least Agile adapts and give you the illusion of the optimal path...but everyone should know that the greedy approach isn't the optimal one and that looking at your feet won't help much going to your destination.
Subscribe to:
Post Comments (Atom)
The particular problem that we are facing right now has little to do with agile and a lot to do with poor design. If your system is built in waterfall mode by architects with little sense of scale, it will still be unscalable. Take a look at Zope 2 for an example of a system built in waterfall mode that ended up requiring massive rewrite to achieve the bare minimum scalability required by a popular web application.
ReplyDeleteMy point was that Agile lead some architects to take the shortess path which is now in our new context considered a bad design choice. With the initial team, a better design will have taken longer to implement and postpone any deliverables which doesn't suit the rapid development need at the begining of the project. Scalibility wasn't an issue at the begining and was representing no buisness benefits....which lead to the no ressource allocation.
ReplyDeleteOn the other hand, the Zodb of zope has been design by anti-sql guys and everyone knows that object related db doesn't scale.
As mentioned implicitly by your comment, a good waterfall project manager will consider a scalable design a critical condition of success even if it leads to slower
development. Every good architect knows that the lately you integrate major architect changes, the more energy will required to achieve it. It is a trade off of short-term/long-term benefits.