My Approach

I’ve been asked on several occasions what my general approach is for software development.

Although I don’t have particular “hard rules” for how things must be done, I do have a number of general approaches which I tend to use on projects.

First, I tend to start with the best people. Using Senior, experienced Engineers, Project Managers, etc, is the foundation to a smooth running project, as well as harnessing their unique specialties. EG I perfer specialists over generalists.

I don’t ask HTML people to set up the database, nor vice versa.

I generally have some sort of written documentation/specification. This is usually 20-50 pages long, and includes screen mockups etc. This document may evolve over time, and does not need to be complete to start coding.

However, having a document in narrative (not wiki) form helps people stay on the same page as well as assists with the onboarding process.

For estimation, I tend to use a range estimation technique, using real time units (hours, days). I will generally take the low and hi estimate them and average them out; using range estimation has many benefits and is probably worthy of its own blog post.

I feel that great communication is key, but colocation is not necessarily a requirement; I work on many distributed projects. Screen sharing, skype, etc, can bring a team from around the country together as well and sometimes better than in person.

However, a certain amount of in person communication is always desirable, up to a point; ad hoc communication is not a substitute for written documentation.

I tend to involve the customer early, and try to shake out unknowns as described below; I try to get the customer to comment etc early and often, and keep a written (or email) paper trail. Written communications provide accountability and a reference and avoids miscommunication.

Since most “change” is readily apparent at the UI level, I will create mocks, prototypes, wireframes, etc, and work with the customer to refine things at this level; shaking out as much change/initially missed requirements early allows the team to avoid much needless refactoring once production level coding starts.

I use loose coupling throughout the system to avoid people synchronizing on changes; eg some production code could start while other aspects are still being shaken out using mocks.

I will generally do an initial architecture of a framework, set up interfaces, and then do performance and usability testing to insure that the framework is operating as expected; I will do at least a few vertical cases to make sure the end to end behavior is as expected; I refine as needed; having solidified the interfaces, aspects of the coding can then be refactored without synchronizing other developers since they obey the same interface.

I estimate in tasks and subtasks, not stories.

I categorize features into 4 main buckets:

  1. Known Knowns
  2. Known Unknowns
  3. Unknown Unknowns
  4. Unknown Knowns

Since the unknowns (can this be done on Android?) are the most difficult to estimate, and therefore have the biggest chance of blowing up the schedule, I tend to do those first. Having done them, the rest of the schedule becomes relatively predictable.

For the unknown unknowns (things we haven’t though of yet) I pad as appropriate. For the unknown knowns (things we havent thought of yet but are straightforward — eg, admin screens) I bring my experience and work with the customer to add in things they were missing in the requirements.

We adapt to change, but we manage the change and changing requirements, not let change for the sake of change, or even worse, change due to ineptitude or laziness, manage us.

Generally the work is performed and released in an incremental fashion, with as much parallelism taking place as possible.

I unit test as appropriate, but generally have more sophisticated “test harnesses” for performance testing than most simple “unit testers” would use for unit testing.

So, that is in general, my overall approach; while  it doesn’t touch on everything it at least should give the reader an idea of how I approach SW Development


3 Responses to My Approach

  1. Vin D'Amico says:


    I like your approach. It’s a hybrid approach combining some elements of waterfall development with some elements of agile development. Starting off with “the best people” is always important. I’m not a fan of lengthy documents but 20-50 pages isn’t bad and including screen mockups is a great idea.

    I like estimating in ranges — it let’s everyone know that there is some uncertainty. And, involving the customer early and often is always a good thing.

    I’d quibble a bit with “pad as appropriate” to manage the “unknown unknowns”. Padding can be a dangerous game because you never know how much padding is enough or too much. If you’re open and honest about the estimates and the unknowns, I suppose it can work.

    I think there is a lot more agreement between us than disagreement. Thanks for commenting at my blog and thanks for letting me comment at yours!


  2. Shan says:

    Very practical. Though many people like me follow same or similar practices, it’s a good move to document this. But more packaging of this by giving it a name and selling will result in the same rhetoric that surrounds the current agile practices. It’s better to just document and leave it to the practitioners

  3. PostAgilist says:


    Thanks to both of you for leaving your comments… Since this page exists as both a “page” and a “post” I would like to solidify all the comments on the “post” page.

    Please repost your comments here:

    Also readers please look for and leave your comments on that page in relation to this article:


Comments are closed.