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 emphasises:
- 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
|
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
|
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
|
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
|
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 summarises 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.
Linkedin 
RSS Feeds 
Newsletters 
Alerts
