Lately my work has been full of exciting developments. Inside of a week, our department head decided to tackle the single largest project in the history of our department. I am not supposed to talk about the specifics, so I apologize in advance for being vague.
The scope of this new project requires significant change in our department from our past approaches. Specifically we will need massive amounts of planning and collaboration with each other.
Until now, all of our assignments have been “Ben, make this, Luca, make that, etc”. Once the application has been written, the developer becomes the maintainer, and troubleshoots any issues with it and writes any updates for it in the future.
Advantages of this approach:
- Faster development (only one person in the driver’s seat)
- Troubleshooting is simplified;Â Problems with program ‘x’ goes to Ben – he wrote it after all.
- Each application is self reliant and self contained.
These could be considered “good thing[s]”, until we look at the disadvantages:
- Mishmash of code bases, and interface design. (Not good for the perceived coherence of your team.)
- Duplication of code
- No integration of systems – which means walled gardens.
- Orphaned applications when the developer leaves the department.
This approach works for the small stuff, but once you step into the enterprise arena, its a different ballgame. Clearly to pull off this beast of a project, we will need to adopt a new development approach.
So off I went to do some research on proven methods of development. I quickly found that opinions on programming methodologies are like assholes as they say, everyone has one, and everyone else’s stinks. After reading overviews of several different methods, Extreme Programming was the only one that made me sit up in my chair. The other methods seemed to reverborate the spewing bullshit ramblings of my Systems Analysis and Design instructor.
An interesting requirement of Extreme Programming requires programmers to work in pairs. An interesting approach, especially since the programming language we will be using (Ruby on Rails) is one that two people on the team are experienced at, and the other two are beginners at. This article on Wikipedia cites many benefits to doing so:
- Design quality: Shorter programs, better designs, fewer bugs. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.
- Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.
- Overcoming difficult problems: Pairs often find that seemingly “impossible” problems become easy or even quick, or at least possible, to solve when they work together.
- Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.
- Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.
- Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email, or other violations of discipline, when they are working with a pair partner. The pair partner “keeps them honest”.
- Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
If our department can adopt this method, colloborate effectively, and communicate politely, I think it will help us on this venture. It will be interesting to see how certain cowboy coders adjust to being part of a team effort.
Zone of Mr. Frosti 