Software development can be maddening, especially when requirements remain murky even as coding proceeds due to deadlines. As the team leader, you’re responsible for results, and so you try to pick the development methodology that will lead to success. There are many methods to choose from nowadays, and that’s where you can get into trouble. As a programmer, you know programming is an art, but as a manager, you want it to be a science so you can predict the results when you follow the “rules.” Following the rules means turning methodological theory into practice. This is the challenge down in the trenches, where the code meets the road.

Agile programming
In the past few years, “agile methods” have been touted as a kind of Holy Grail of development methodology. As defined by the Agile Manifesto, the term “agile” is any method of building software that emphasizes:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

These principles aren’t a method, but rather the guiding framework upon which you can build a unique development style that fits your corporate culture while embracing the concepts of agility promoted by the manifesto.

Look at Figure A to see what the first agile guideline can mean for you as both a programmer and a manager.
Figure A

First guideline

Programmer perspective

Manager perspective

Individuals and interactions
Finally! I get to allow collaboration among team members to determine the release date rather than back-fill the schedule from the boss’ uninformed expectations.
Hold on! You mean I have to trust the programmers and business analysts to set the agenda? Sales depend on meeting a deadline, so the team is just going to have to live with my date!
Process and tools
Yuck! We have to go through all these committees, processes, and tedious documentation to define what we already know how to build.
Great! At least I’ll have a sense of control and be able to measure progress as development proceeds.

I’ve set up a bit of a straw man in the list above, in case you didn’t notice. The two perspectives, programmer and manager, are both yours to own as the leader of the team. This is where theory meets practice. As a manager, you want control over every aspect of the development cycle. As a programmer, you know that even the best designs can change your well-conceived plans. Balancing these two perspectives is what creating a workable method is all about. The agile school says that the balance should be tipped in favor of individuals and interactions. This can leave the manager in you feeling a loss of control. Well, you may have to get over your need for control if you want to have the flexibility to adapt to changing requirements while the coding proceeds. Have you ever really worked on a software product where the requirements were truly complete before you began coding? I didn’t think so.

How about the second guideline? What does it look like from your dual roles as manager and programmer? A bit like Figure B.
Figure B

Second guideline

Programmer perspective

Manager perspective

Working software
This is what they want, so what’s not to like? I’ll make sure it works.
Yes, this is the goal, and testing takes time; programmers aren’t the best testers.
Comprehensive documentation
It will be out of date after the next version. Why bother? (Or, the deceptively simple view: The code is the documentation.)
Yeah, but how does it work, and will anybody be able to maintain and extend it? Users want help files, and design documents are needed.

Again, you must see the merit in both views and strive to seek a balance in your development methodology. Everybody wants working software, but unless it has some associated metadata, neither the programmers nor the customers are going to be able to fully appreciate the details or the way-cool features.

Let’s look at the next agile guideline. We’re building some momentum here that can help you put some method in the madness you struggle with daily. Take a look at  Figure C.
Figure C

Third guideline

Programmer perspective

Manager perspective

Customer collaboration
Wow! Actual users are going to evaluate my interim builds? This should really help.
This project will never end because users always want to change things.
Contract negotiation
This is not what I signed up for. Let the lawyers deal with this.
If we agree to a fixed set of features, then we can control the development effort.

Sometimes programmers shy away from dealing with customers, but we all know that understanding the users’ needs is the only way to build truly great software. Managers, of course, are concerned with scope creep, but if you deliver a product that no one can use, have you made the right choice? Again, balance is needed and, since no one likes lawyers, I would vote for the collaborative approach.

Finally, the fourth and final guideline can present the views in Figure D.
Figure D

Fourth guideline

Programmer perspective

Manager perspective
Responding to change
I do this every day. For example, yesterday’s test results dictate that I must change the design if this product is going to come together.
Change is bad! I will make every effort to resist it. The requirements must be fully defined up front.
Following a plan
I’m not a machine! I want some freedom to be creative in my work.
This plan has been thoroughly thought out and, if executed properly, will produce the desired results.

Sure, plans are good, but nothing is worse than executing a plan when it produces software whose requirements were not fully understood in the first place. Sometimes, when you execute a plan blindly, you’ll get what you planned for—it just won’t be what you really need. On the other hand, without some kind of plan, your programmers will just code what they feel is important, and you’ll still miss the mark. Obviously, you need to strike a balance between these two opposing perspectives. Your method must seek to combine the best of both ways of seeing the path to a solution.

I’ve given you lots of theory, and here’s a bit more. Walt Whitman, in his great poem Song of Myself, said in closing: “Do I contradict myself? Very well, then, I contradict myself, I am large, I contain multitudes.” Whitman summarizes nicely what it means to develop a practical methodology: you must hold seemingly contradictory demands in a dynamic tension that allows the fluid requirements to be eventually encapsulated by software solutions that are “good enough.” You’ll never get everything right or complete in Version 1. That’s why we have “maintenance releases,” a term often viewed as hilarious from a pure engineering perspective but truly correct in a practical sense and, thus, linguistically accurate.

In future articles, I’ll explore some of the agile methods proposed in current literature as well as look at the more traditional ways of building software. Please post your comments so I can see if I’m helping address your madness or if I’m simply crazy myself.