‘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
- Document requirements (or change to requirements) to scope level
- Get client signoff (FORMAL REVIEW)
- Document code design, changes to object model, peer review
- Review design (FORMAL REVIEW)
- Update system design document
Implementation
- Implement test cases
- Implement compiled stubs
- Review Stubs (FORMAL REVIEW)
- Implement services
- Integration code
- Code review (FORMAL REVIEW)
- Update documentation
- Documentation review (FORMAL REVIEW)
- Implement review changes
- Final commit and addition to main build
You touched a nerve. One of my pet peeves with myself and others is not being thorough and complete. No matter how good you are at your work, or how long you have done it, you will have blind spots, make mistakes, and leave holes – sometimes big ones. That is why the review process is so very important. It’s purpose is to make the project deliverable – data flow, code, documentation, whatever is being handed to the customer, as complete as is humanly possible. Everyone has a stake in success.
Years ago I worked on a project team along side one of the Big 5 consulting firms. I was lead on a project “module,” and one of my jobs was to review the design and code that the consultants produced. In one review I discovered over 130 defects in code that was supposedly ready for user testing. I wish I could say the consultants learned from their mistakes and the project completed successfully. However, this so-called Big 5 consultancy was very consistent in their lack of quality control. The project failed and literally ended up on pallets, to be hauled off the business property. Millions of dollars, and years were wasted, and professional reputations were ruined.
Quality and consistency are supported by good process, but process is not enough. It has to be part of the company’s culture. It is uncommon to find individual consultants in one company as committed to professionalism and quality as Armedia’s are.
Thanks for the comment Bill. You are right about quality needing to be a part of the company culture. Getting lax on process though is an easy trap to fall into–generally falling into the “we don’t have time for this!” or lip-service category. I think an area companies need to pay a lot more attention to is providing valuable and in-context incentives for people to truly adhere to these processes; the reverse is also true of course…see Freakonomics.
You’ll shop between products from some of your planet’s most prestigious home furniture designers and manufacturers