Armedia Blog

‘Tis the season for the big sales kickoffs, goal communication, quota setting and the inevitable fudding and jockeying that goes with that. We at Armedia are, of course, not much different and have been dutifully working our list for a while. All roads therefore lead to “Are we done yet?!” Well, some things may never be completely done. And, sometimes, you just don’t know if you’re done or how done is done. That’s kind of like dreaming about having a dream about having a dream…will it ever end! As intriguing as such enigma could be chances are you don’t want to deal with it when it comes to software development. In fact, unless you plan on becoming further fodder for Dilbert, that’s about the last thing you want to do.

So, how can you achieve “doneness” in software development? There are, presumably, lots of ways…and likely at least one or two not based on divine intervention! Based on our experience, doneness in development (particularly in large projects) is not as much to do with having a cadre of stud developers but having a thorough, systematic and review-laden process that is consistently adhered to. Who knew?!

Here is the gist of our approach to doneness (formal review steps are highlighted in brackets—cannot proceed to subsequent step unless review passes successfully):

Code Design

1. Document requirements (or change to requirements) to scope level
2. Get client signoff (FORMAL REVIEW)
3. Document code design, changes to object model, peer review
4. Review design (FORMAL REVIEW)
5. Update system design document

Implementation

1. Implement test cases
2. Implement compiled stubs
3. Review Stubs (FORMAL REVIEW)
4. Implement services
5. Integration code
6. Code review (FORMAL REVIEW)
7. Update documentation
8. Documentation review (FORMAL REVIEW)
9. Implement review changes
10. Final commit and addition to main build