If you are a newly-minted developer, you’re looking around you for guidance, best practices, and reassurance that you are more or less pointed in the right direction.
That’s one of the things that creates the demand for methodologies — canned and packaged approaches to software design and development that promise efficiency, accuracy, timeliness, and reproducible success. That’s something any developer worth his or her salt wants to provide his clients.
Another thing that generates the demand for many methodologies are the real and perceived needs of other stakeholders in the development process. Managers need political cover; marketroids need products that are easy to sell; top management need bottom-line justification and predictability; bureaucrats need forms filled out; bean counters need hard and fast numbers; and so on.
It would be a mistake to imagine that methodologies exist soley to serve the objective of producing quality software. It would be an even bigger mistake to imagine that they can’t be manipulated by various interested parties, to their own ends — ends which may be diametrically opposed to quality software.
Don’t get me wrong; I’m not opposed to thinking deeply about craftsmanship and trying to improve it. I’m not opposed to systematizing knowledge and wisdom into a set of principles that are readily communicated.
However, I’ve learned to respect the fact that, as Fred Brooks said so long ago, software development is inherently difficult, and there is no silver bullet that will fix that.
Ultimately I have borrowed a little from each methodology I’ve learned about — and I use what I borrow more on some projects than on others. My choices are influenced by the kinds of projects I work on, the kinds of clients I have, and what works best for me personally.
For example, while I like some of the principles of Extreme Programming (XP), it is too much like a religion to suit me, and parts of it — like pair programming — are antithetical to the way I work. To me, pair programming is suitable for some mentoring scenarios and other than that, I can’t think of anything that would make me less effective as a developer. To me, development is about getting into the flow, and that kind of focus is critical to productivity. Maybe somewhere, in some universe, pair programming as a general practice works (in reality, rather than just because people believe in it) — but it doesn’t work in my universe.
When you encounter stuff like this, don’t be afraid to reject it. Keep an open mind, and evaluate everything as completely and objectively as you can, but trust your judgment and your common sense. If it doesn’t work for you, go find something that does.
Another factor to consider is the kinds of projects you typically pursue. Although there have been notable exceptions, I generally stick to small to medium sized businesses, or smallish autonomous departments or divisions of larger companies. And I generally stick to projects where the customer is willing to leave decisions about languages, platforms and techniques to me, so long as the end result works well and is properly integrated with any existing infrastructure. I also don’t take projects with arbitrary, aggressive deadlines that have no relationship to what is actually possible and feasible, technically speaking.
For me at least, this is my core methodology: avoid death marches, under funding, and the whole responsibility-without-authority thing that is so common in business. It takes care of a lot of crap that methodologies often are adopted to compensate for.
You must recognize that almost everything about business, including development methodologies, consists of both facts and bullshit. Learn to identify the bullshit and work towards situations where you can eliminate it as much as possible. Learn to turn the BS to your advantage.
For example, as I write this we are in the throes of a software development offshoring fad. Offshoring is not a development methodology as such, but it’s a close kissing cousin — a development management technique. Cash-strapped managers have been seduced by inexpensive slave laborers, because they don’t understand that developers don’t manufacture commodities using rote steps. Offshoring works, in the short term, because it makes a hero out of the genius who adopts the concept, allowing budget and staffing cuts. By the time the problems come home to roost, he has already gotten promoted and the blame comes to rest on his hapless successor.
(Offshoring also illustrates another misuse of methodologies. Many offshore companies advertise their ISO 9000 and/or SEI compliance like magic totems. And indeed, they are magic — because many buyers of offshore services don’t realize that all ISO 9000 and SEI define is a standard process. If you have a bad design, all that gives you is a good process for acheiving your lousy design).
At first I found this trend dismaying. After seeing my hourly rates rise by a factor of almost ten over a period of 15 years, I saw myself being bypassed in favor of script kiddies elsewhere on the planet who were underbidding the rates I started working at in the early 1980s. And it wasn’t like these folks were matching or besting what I had to offer; in general, they were of abysmal quality.
Ultimately, though, I found that I have clients willing to pay me good money to manage their slaves contrary to my advice, and clients willing to pay me even better money to mop up after their slaves. It is poetic justice, and a perfect illustration of what I’m talking about. Methodologies and management philosophies come and go, and surviving the constant churn is a matter of learning a sort of jiu jitsu to make lemonade from lemons.
Notice what I did NOT say about XP, and offshoring. I didn’t say that neither has any value at all, or no place at all. Much of XP can be used, on the right projects. Offshoring can make business and sometimes even ethical sense, on large enough projects where you can open an offshore office and manage it correctly. But neither is a silver bullet, and you should not be swayed by them just because they happen to be riding a wave of popularity.
Both XP and offshoring are largely driven by fantasies (“skip the analysis phase!” “cut your labor costs 90%!”) and it’s just another example of how most business decisions are emotional, rather than rational. Realize this and act accordingly.
