Matt Heusser wrote this beautiful piece of writing about software development practices – quoting another famous Blogger Joel Spolsky.
"... which has a programming method in which programmers code stories based on notes written by designers that are based on requirements documents created by analysts that are assessments of what the customer actually wants. It's practically designed to get everything wrong, to insure that, no matter how ignorant the analysts and architects are on an issue, they'll find someone who knows even less to write the actual code ..."
It is interesting that with so many "loose" ends and human elements (thinking, question, modeling and analyzing), many still fancy the changes of "zero defect software", compare software to manufacturing, glorify processes to fix the problems in software that is INHERRINTLY designed to GO WRONG. If you look at the chain of analyst ->Designer->developer ->tester -> Customer, each one works with less or totally different set of information than all others.
Notice what Matt has to say – to make sure that they get the final software wrong – they will find someone who knows probably the least to write actual code !!!!
How can this (software) EVER GO RIGHT? Can this?
Read entire blog post here …
Shrini
4 comments:
Considering the theory of constraints and lean manufactoring, it is no wonder for me that this chain you describe is inefficient. Each interface (the arrows basically) has some buffer attached to it. In this buffer the decisions that flew into the actual work products assigned to the actual person get piled up until submitted to the next chain member to validate. When considering a usual software development project then there are a lot of decisions piled up into the buffers before getting feedback from the next - or even worse - from the overnext or even last member in that chain.
More interesting here is, that the learning curve attached to it gets influenced by the time it takes to get feedback on the work. What can an analyst learn from a feedback six months later? Even worse, what other projects did he do in the meantime without being influenced by that very valuable feedback?
Markus,
I am not sure if you can apply the analogy of theory of constraints and lean manufacturing to software.
The chain of "Analyst->Designer->Programmer->Tester" is a highly simplified version of what happens in a typical software development project.
Another thing that is how to define throughput in software? Do we make replicas of an approved prototype? So, I am not sure if there are any practical examples of applications of TOC to software.
The point your make on feedback loop is valid and evolving development models such as Agile aim to cut down the feedback cycle time and make feedback available to the recipient in quickest time possible so that "work" does not pile up.
Worse - process fanatics make feedback loop really go out of control in the name of repeatability and controlability and impose mindless documentation and approvals.
Shrini
Well, concerning the applicability, most texts on agile try to make a point here. There is even an agile methodology called after lean manufacturing. The point you raised is true, though, since you have to keep in mind, that the software domain is not really comparable to manufacturing, where you really can re-built the same product each day. But as pointed out in Agile Software Development with Scrum, there is no deterministic process in software development, it's an empirical one. This fact calls out for regular reflection and continual process improvements and short feedback loops.
In a sense I'm still interested in the Schools of Software Development and how the combination with each School of Software Testing would look like. But that again might be a search for the Silver Bullet, that does not exist.
>>Notice what Matt has to say – to make sure that they get the final software wrong – they will find someone who knows probably the least to write actual code !!!!
As a designer/analyst, I've worked with several SW Engineers that say "I don't care what the system is supposed to do, I just want to write code."
It's my take that it's a rare few who both want to and are able to write code AND have interest in the end-users experience.
So, I conclude that these practices to remove the developer from the actual needs may be, at least in part, a result of that attitude.
Thoughts?
Post a Comment