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:
- Known Knowns
- Known Unknowns
- Unknown Unknowns
- 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