Although it may be an overreaction, what is it a reaction to? Many statistics show that even today, most software projects fail. It seems reasonable to believe that many companies are looking for a new way of doing things. From the programmer's point of view, it probably seems like it is a failure of management and a lack of proper tools to get the job done. If that's the case, it would make sense to try to minimize management and throw out the old tools.
On the other hand, there's the famous adage that managing programmers is like herding cats. From a management perspective, it can be frustrating as well: "why don't the programmers understand how important it is to get feature XYZ completed by the deadline?"
I think the truth is probably a combination of things; insufficient understanding by management of the complexities of software development, lack of reliable visibility into the plan and current status, overly complex and insufficient tools, insufficient understanding by programmers of the complexities of business realities, and lack of information in the trenches about how the current development plan is connected to the business plan.
It seems to me that part of the problem is plain and simple education. Having been in both camps, often simultaneously, I can shed some light on this subject, but my favorite part and the part I think tool vendors can help the most with is providing tools that provide high visibility of all aspects of the software development process to all stakeholders in real time.
After all, isn't the fundemental reason for software the automation of manual processes? Why in the world should software developers ever have to resort to keeping track of things with 3x5 cards or spreadsheets that provide only a modest benefit over paper and pencil compared with using a software tool that has been tailor made for tracking software development activities? What's next? A return to punch cards?!
As a software development tool vendor, I believe we are obligated to sit up, take notice, and do something about this situation. Otherwise, it seems that we can look forward to state of the art software being created with the software equivalent of sharp sticks and stone knives.
One company that has started to respond to this challenge is the Rally software company with their Rally software product. It automates many of the tasks associated with Agile development. I salute their efforts and hope that all tool vendors will respond in kind. I know that I'll be doing my utmost to make sure that AccuRev takes heed.
2 comments:
Hi Damon!
I believe Extreme Programming (XP) and other Agile Methods are indeed a strong counter-reaction to some prevailing management and industry trends from arround 1985-1995.
I think the issue ultimately revolves around empowerment and control. During 1995-1995 two very significant things became very trendy and management and organizations bought into their ideas: The SEI Software Capability Maturity Model (CMM), and Computer-Aided Software Engineering.
During this same time, programming and design methods were all caught up in the hype of object-oriented programming+design, and iterative+incremental development.
Many a large organization (and small ones too) tried to latch-on to one or more of these things as a "silver bullet." Many misinterpreted and misimplemented CMM and CASE as a magic formula for creating successful software with plug-and-play replaceable developers/engineers:
* Lots of process documentation was created
* Lots of procedures and CASE tools were deployed with lots of contraints regarding what they may and may not do
* and "compliance/conformance" to documented process was audited against.
Many felt that the importance of "the people factor" had been dismissed, and that creativity and innovation were stifled by such things. And many felt disempowered from being able to do their best work and do the things that they new were required to be successful, because "big process" and "big tools" were getting and their way and being forced upon them.
(Some would liken this to the classic debate between Hamiltonian and Jeffersonian philosophies of "big government" and highly regulated versus "that governemnt is best which governs least")
I think this is the "crucible" in which Agile methods like XP were forged. They wanted to free themselves from the ball and chain of restrictive processes and disabling tools.
So of course, what do we do when the pendulum swings so far out of balance in a particular direction that it really makes us say "we're mad as h-ll and we're not gonna take it any more!" ??
Answer: we do what we always do, we react with too much countering force and instead of putting the pendulum back in the middle where it belongs and is "balanced", we kick it as far as we can in the other direction. And we keep kicking as hard as we can until we fell "empowered" and "in control of our own destiny" again.
Then we don't look back and see when the pendulum (or the industry) starts self-correcting about every 10 years or so and starts to swing back and bite us again :)
XP started around 1995 and this years marks its 10th anniversary. Agile methods have been officially embraced by industry buzz somewhere around 2002, and for the last couple years, there has been some work on how to balance agility with large organizations and sophisticated technology.
Among the main things coming out of it that are generating a goodly dose of much deserved attention are:
* testing and integration/buidling are getting emphasized much earlier in the lifecycle, and by development (not just testers and builders)
* the "people factor" and teaming and communication is getting "equal time"
* iterative development is being heavily emphasized up the management hierarchy - and not just iterative but HIGHLY iterative (e.g., weeks instead of months)
These are all good things.
There are some folks out there who never forgot them to begin with. They never treated CASE or CMM as a silver bullet and took a balanced approach from the start. And they didnt treat "agile" as yet another silver bullet either. And they have been quietly delivering successful systems without a lot of noise - and we didnt hear much about them because they werent being noisy.
Unfortunately some other things may seem like they are "babies" being "thrown out with the bathwater". Agile puts so much emphasis on the development team and the project - that several of the methods do so at the expense of other important disciplines and roles across the organization (including, and perhaps even especially, CM)
---------
After all, isn't the fundemental reason for software the automation of manual processes? Why in the world should software developers ever have to resort to keeping track of things with 3x5 cards or spreadsheets
---------
Software is used to replace repedative manual processes. In practice the use use of cards works well. To be blunt if you havn't tried XP with cards you are not qualified to comment on thier suitability.
Post a Comment