On development methodology
Give me the smallest, smartest team possible, with the right tools and infrastructure. Work like fiends for two or three months to get infrastructure and applications started right, then grow slowly to maintain and build additional applications on the core technology.
If you have too many smart people, they’ll have conflicting ideas about how to proceed. (“Eagles don’t flock” – there’s a reason.) If you have too many average people, the smart people will spend all their time supporting the average people.
Break software into the right modules, eliminate as many dependencies as possible, prototype systems, and build complete systems as fast as possible – implementing only the essential requirements and using the smallest possible team to do it.
The somewhat artificial pressure to build fast is a key ingredient to success. It enables you to postpone changes to requirements while you build, it shortens the time period in which changes to requirements can be requested, and it means that you can’t even begin to implement all requirements, thus giving the technical team a little more leverage about what goes into the first release.
Methodologies
There has been an unending series of fads in software methodology. What can you say about them? They have a failure rate of about 85%. They enforce bureaucracy. They provide a common language and direction. If everybody learns the buzzwords, folks can at least sound like they are talking about the same things.
Methodologies by nature are designed to coerce large teams to approach tasks uniformly, and to provide some cover to managers who can say they were following the methodology, even if the project is late, over budget, and doesn’t work.
Each new methodology brings unique buzzwords, acronyms, nouns, and verbs – all describing the same fundamentals with proprietary, obfuscatory vocabulary. What they have in common is that they fail five sixths of the time.
I’m always baffled by their techno-babble: once, before I understand it, and a second time when I do. How can you – straight-faced – create a methodology around examining the scenarios in which a system will be used? If you weren’t doing that before, were you smoking crack?
Organization structure
An eWeek article told the story of a meeting room full of company executives, with the thermometer set at 62 degrees. Everyone was very uncomfortable, but no one said anything. Only after twenty minutes, the CEO got up and changed the thermostat setting. If it takes the CEO of a company to change a thermostat (sounds like a light bulb joke, doesn’t it?), what hope does the company have to base development on skill, talent, and information?
The alternative
Methodologies are rooted in the idea that you can plan everything out in advance, and build the pieces, and end up with the right thing.
Even if it were realistic to define large-scale systems completely before coding begins, and then prevent any changes to requirements until after the system is done, would you want to?
“In terms of game theory, we might say the universe is so constituted as to maximize the play. The best games are not those in which all goes smoothly and steadily toward a certain conclusion, but those in which the outcome is always in doubt. Similarly, the geometry of life is designed to keep us at the point of maximum tension between certainty and uncertainty, order and chaos. Every important call is a close one. We survive and evolve by the skin of our teeth. We really wouldn't want it any other way.” - George Leonard
We see that business directions can change dramatically over night, and may change frequently: in a period of weeks or months. If you build an organization that cannot keep up with fast changes, your business will crumble. To be able to change quickly, you must make a practice of changing quickly. There really isn’t a lot of choice any more.
Technological Advance
The most astounding change over the twenty years has been the scale of problem that a small team can solve rapidly. With a team of five developers, I can build the most complex commerce website in two months – on the order of complexity of projects that took dozens of developers years to implement, not long ago. In fact, of course, the web-oriented application – built on the infrastructure of the internet – is orders of magnitude more valuable.
If current methodology fads seem to work better than previous, surely you can account for it just in the improvements in hardware, infrastructure, and tools. For example, Java has too much overhead to have been successful on 1990 hardware.
Of course the technologies available to developers are a small part of the issue. The smartest, best team of developers can be rendered completely unsuccessful by management decisions.
I suspect that the last twenty years’ worth of methodologies were mostly thwarted by social, rather than technological issues. Hordes of hapless developers were thrown against huge, ill-defined problems with essentially inappropriate tools and wrong strategic guidance. Successful projects were the result of smart teams and isolation from bad management decisions, rather than the benefits of any particular methodology.
Where are we now?
I think in many situations it is easier to build the 20% of features you need, than to integrate someone else’s application and turn off the 70% of features that you don’t want.
One of the most productivity-enhancing trends in the last few years is the lower-quality user interface. Rather than waste time writing, formatting, printing, and distributing the perfect memo – based on the perfect memo template – send an email... with misspellings and grammatical errors. Rather than fritter away days to make PowerPoint slides, draw on a whiteboard. Rather than create client-side Visual Basic interfaces to database applications, use html in a browser. Rather than rewrite a server-side database application, leave the existing code in place and put a web front-end on it.
Why are low-quality interfaces important? Consider the rule of thumb that says it takes one unit of effort to do the first 90%, one unit for the next 9%, and one unit for the next .9%. Stop with the first 90%. Don’t go for slick, flawless perfection. Consider another rule of thumb: you get 80% of the value from 20% of the features. Stop at 20%. Fewer features allow less room for bugs and user errors....
While your competitor struggles ten months to implement the extra 80% of the features, you’re live in two months and on to the next application. The customers who want 100% of the features with old-fashioned desktop interface quality – let them eat Microsoft Office. Meanwhile, you provide the good-enough user interface and keep developing at the rate that your customers want new applications: fast.
How far can you take this?
ERP projects have been the ultimate business software disaster. Over and over, companies have invested outrageous amounts of time, money, and talent on projects that usually failed miserably. Worse, the fundamental conception of the projects was that the practices of the company must change to conform to the software they buy. Talk about smoking crack!
OK. So they were all big projects, and the consultants claimed to know how to do it, and the company sure as heck shouldn’t have tried to do a one-off solution.
Or should it have tried for the one-off solution? Always there’s this pendulum swinging between monolithic software and interfaces between uncoupled systems.
Internet technologies should radically reduce the cost of integrating uncoupled systems through automated interfaces. This should dramatically increase the scale you could manage without an apocalyptic ERP system.
I suppose there will always be “black” reasons for choosing ERP systems, but I emphasize that the scale of company that can avoid that particular nightmare has just leapt upward.
Technologies and teams....
If you are going to base your development on talent and skill, rather than numbers and methodology, there are certainly still issues to deal with.
You have to find or grow the talent, and keep it once you’ve got it. Few companies treat employees as anything other than disposable, so this is a fundamental issue. You do the right thing(s), or you don’t.
For any technology you use, you need at least three people: one very smart, one who can grow to take over leadership, and one still challenged at a more basic level. Why three? What if one quits, and another gets sick or goes on vacation?
To me, this says to reduce the number of technologies. If you use four technologies, it’s scary to have less than twelve people. If you use one technology, you can have five people and not be scared.
This breaks down with the database. Database companies, up until now, have rigged it so you need one development team outside the database, and another inside, writing stored procedures, triggers, and defining views and such. Maybe then it’s good news that the database companies are now out to take over the outside development. Oracle “i” databases are intended to put the application development into the database, in Java. Oracle’s incentive, of course, is that they license by processor power of the database server. If you do all the processing there, you need a much bigger processor (there), and so Oracle earns vastly more revenue from the same installation. But it may well be a good thing, because then you only need the one team of developers.
Build fast
Another principle is to have your smart developers coding. Use project managers to communicate and write documents.
But mostly, avoid writing long documents. Yes, write them for complex applications that have to be absolutely right. But most web stuff isn’t like that. It’s faster to make many changes than it is to write the documents to support them. See how many requirements documents you can write that are one paragraph in an email. Often, write documents after the system is online, to support future maintenance.
De-compose systems into very small pieces that can be changed easily and quickly.
Instead of hiring 20 Java or C++ developers, hire 3 very smart scripting people. Python or Perl (for example) are likely to need an order of magnitude less code to complete an application, and 3 developers need an order of magnitude less coordination and documentation. Smart developers are typically an order of magnitude more productive than average folks. All in all, three smart people writing in a scripting language will run rings around twenty people working in Java.
On top of that, consider how long it takes to hire twenty developers, much less set up their workspaces and support them. Writing web applications, your team of 3 could be done before the team of 20 is even ready to start.
Caveats
Even if you build fast, you still have to maintain code over the long run. This requires forethought, structure, and communication.
Copyright © 1998-2011 J. R. Boynton