This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Commonly Heard, Uncommonly Thought
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
A commonly heard Myth: "A project with good developers will succeed no matter what their process."
So, no matter what their process, success is caused by "good developers" and failures are caused by "poor developers"? That isn't the case. A project with a bad process, will likely fail, no matter how good the developers are, unless the developers circumvent the process. The irony is that a "good developer" breaks the rules in this circumstance, while the "bad developer" follows the process rules. Too often developers are classified into "bad developers" and "good developers" because of systemic failures outside of their skills as programmers.
For example, if the domain is complex, and the process is "One month of analysis, followed by two months of design, followed by four months of programming, followed by three months of testing". (Dates fixed no matter how complete each of those activities is.) Well, that is only going to work if the team members actually do all of the activities (analysis/design/coding/testing) all the time. Testing during the design phase (perhaps via coding or by programmers "playing computer"). Thinking about coding, or actually coding, during the analysis phase. Revisiting analysis, design, and coding during the testing phase.
Very likely in such a 10-month "phased" project, they will find they are in trouble after the second month of "testing" (which often really means "bug-fixing"). At that time they will be forced to fix the flaws in their analysis, design and coding, with much grumbling and angst, and that "testing/bug-fixing" phase will end up lasting six months or longer instead of the planned three months. Sixteen months instead of 10 months.
Another myth is: "A project with bad developers will fail no matter how good their process is." (or "A good process won't make good developers out of bad ones.") This is also false in some situations, depending on how one defines a "bad developers". If it merely means "inexperienced", then depending on how well their process encourages detection and correction of mistakes, the simplicity of the domain, and how often and how well the developers get feedback from customer-proxies, domain experts, or end-users, the project could well succeed. If "bad" means "refuses to learn" and "refuses to cooperate", a good process will at least reveal those problems, but a bad process will let those problems stay concealed until disaster strikes.
This is why some poorly skilled developers are so against agile methods: their deficits in coding/testing skills or people-skills will be revealed by an agile method, and they would rather hide in a high-ceremony or chaotic process. Skill-deficits can usually be remedied by training, practice, and mentoring but only if people involved are motivated, and situation permits learning from mistakes.
In a chaotic "no process" situation, the advantage lies with the highly skilled/very-experienced developers who can write code with few defects, and who know enough to adopt a good informal process for their own work and for the work that's essential for the project's success. The other success factor I've seen in the "no process" situation is done by less-skilled developers: they work extra-long hours fixing mistakes that a good process would have prevented in the first place. I consider such overtime to be management failure.
"Success" can be very arbitrary, of course. In the history of software development, it's been fairly common for a horrible product to be declared a success and shipped. If that situation were uncommon, we wouldn't have license agreements that declares the software company is not liable for defects or even fitness for use.
More and more, software surrounds everything we see, touch, ride or fly in. My car has maybe a dozen CPUs running software for anti-lock brakes, digital dashboard, monitoring and controlling the engine, and so on. My "sonic" toothbrush maybe has a CPU as well. Clocks. iPods. Email. Phones. Chats and IM. Spell-check. Word-processing, image processing. Search engines. DNS. If your work is entirely digital, you're at the mercy of software all the time. Let's hope that the software we use is good enough; or we can do more than hope ��� we can learn good practices and good processes, seek feedback, and make it better.
Previous Topic
