Rusty Divine

Live, Love, Learn, Teach

House of Software Development

We've started a software developer's book club at work, and our first book is Code Complete, 2nd ed. by Steve McConnell - probably the highest recommended book on software development today.

Our division is just starting to organize itself from a staff-augmentation focus where we'd help out clients with relatively quick and easy programming solutions to a structured software development focus. It's more of an attitude shift than a job-type shift, really. We aren't going to start selling shrink-wrap, we're just going to start laying down some procedures and standards and a methodology of sorts.

Coincidentally to reading the first chapter which reviews the major aspects of software development and discusses different analogies (including that of building a house), my boss asked me last week to basically define my own role in the new hierarchy, which itself is still being defined daily.

So, I smartly put together the following diagram based on Steve's ideas, and told my boss that I wanted to be improving techniques and finding tools for the "green level" in the cartoon below, and as my career progressed, I wanted to move into the "blue level". He has a software background from a decade ago (COBOL), and knows essentially what it's all about, but I think he was really impressed with the clarity and completeness of the analogy. Suffice it to say, he forwarded my silly cartoon (which he loved, since he has a good since of humor) to the group including the text that said I was in charge of the "green level" and would later be in charge of the "blue level". Nice :) Now I owe Steve a bottle of champagne, too.

This is the house of software development. Like any building, the house is only as good as its foundation, and as you continue building to the roof, the higher levels are dependent upon the lower. There are other components not shown here since they are outside of our group (like infrastructure, which would be like the plumbing, and sales, which would be like the people living in the house who are trying to sell it).

The different color gradients represent different roles or responsibilities.

  • Purple – Problem definition, and requirements gathering are done by a business analyst. Output includes scope, functional spec.
  • Light Blue – the design and architecture are done by a senior developer by using the documentation of the lower level. Output for this level includes technical spec and may include the database and data logic on medium to large projects. This level sets the tone for the rest of the project (decides if dedicated testers needed, what level of testing needs to be done, what procedures need to be used, number of developers needed)
  • Green – the programmers take the documentation produced by the lower tiers and start constructing the code. Output includes code, GUI, and possibly unit tests depending on small to medium sized projects; larger projects may have dedicated testers.
  • Orange – the overall testing, support, and QA/QC sits on top of the house. The system testing includes pre-release testing, issue tracking, and post-release support. This role has the final say on quality and effectively signs off on the project. When issues come in post-release, this role directs those issues back to the green band for corrective maintenance, but provides the tool for tracking issues.

Learning Design Patterns – Template Method Pattern

This week I'll be examining the Template Method Pattern in my series on design patterns plucked fromthis book and from examples on the Internet.

What is it?
The Template Method Pattern lays out the steps in a process (algorithm) and allows subclasses to handle one or more of the steps internally. The pattern has a method that just contains a list of method calls to complete the process (create something, package it, sort it, deliver) that can not be overriden or augmented. Some of the process methods may be handled by the pattern (create something and deliver), while it makes the subclasses handle the others (sort it, package it).

The pattern also can have "hooks" in it, which are methods that have no implementation, or a default implementation, that the subclasses can choose to override or not.

Where is it used?
The Template Method Pattern is one of the most frequently used patterns around. It especially comes in handy for developing frameworks.

But why?
The Template Method Pattern encapsulates algorithms, and is used wherever a process, or some steps in a process, are being duplicated by classes - the pattern allows the code to be refactored so that the duplication can be eliminated by pulling that code into the pattern.

OK, and how is it implemented?


abstract class ShipSoftware {

	//declare the template method final so that it cannot be overridden
	final void ship {

	//make the subclass decide whether to put the software
	//on a CD or DVD or other medium
	abstract void createMedia();

	void packageMedia() {
		system.out.println("Putting software in a box");

	void postalSortByZip() {
		system.out.println("Sorting packages by zip code to decrease shipping rates");

	void deliver() {
		system.out.println("Drop off packages at Post Office");


public class ShipMyNewestProduct extends ShipSoftware {

	//implement the creation
	public void createMedia() {
		system.out.println("Burn software on CD");

Adopt a mentor

It was only a little more than a year ago that my supervisor sent me a link to Joel's site on software development. Hard to believe how far my career has come since then! I've switched jobs am no longer an under-paid grunt, and I credit a lot of it to Joel's site.

It didn't take me long to adopt Joel as my mentor. His essays on software development, and the crowd of great folks who contribute to the forums, woke me up and got me interested in software development as a craft. I started using his painless software scheduling, and more importantly, started reading the books on his book lists. I started off with the two classics Peopleware and The Mythical Man Month - talk about eye-opening books!

When I started my current job about 9 months ago, I was the only full-time developer in the office of an international consulting company. I was assigned a few small projects at first and was able to use Joel's template for functional specs, and his spreadsheet for schedule tracking. I installed a source control system, and started trying to improve the system from within to bring our division's score up on the Joel test. I was doing things the grunt way - doing what I could with the power I had to use the tools I wanted on the projects I was working on.

Management took notice of the good job I was doing. People were raving about my interview questions and how I actually made applicants write code in the interview. When the division organized itself from flat and ambiguous, to structured into stove pipes like sales, app development, etc., I was able to use it as an excuse to pull every developer in the region (about 5 offices, 10 developers) into a community of application developers. I created a Groove workspace for us all to collaborate and share code snips, talk about standards and patterns and practices, and jell as a team. For the first time we'll be working on projects together even though we're in different offices, and jelling as a team will be very important.

At my annual review I was surprised with a large raise, and just a week ago I received a call from my boss twice-removed (two tiers up). He called to say what a great job I was doing and how he expected everyone in the office to be working for me one day (ha!), then he gave me a big bonus! It was incredible - no one at my level gets bonuses at our company; they are reserved for the elders who are paid too much to give big raises to.

So, I just want to take this opportunity to publicly thank Joel for being such a great mentor. It takes a lot of effort and a lot of guts to put all of his opinions out on his site, and I think he provides a great service. All said, since I've adopted him as my mentor just over a year ago, my salary has increased by 50% and my career has really taken off. I should really send him a bottle of champagne! I'll have to ask him what he likes.