Since joining TW (some 18 months now), I have been wanting to write on the key software dev practices that stood out from my previous work places. Here you go:
Everywhere else I have worked, there is not a lot of attention to be productive at work. It might appear self serving in time and material projects but the real reason is that there is a lack of introspection to see how to build effective software development practices.
Investments in continuos integration, automated database migration, functional test automation, push button deployment pay off in compound interest.
As Paul Graham writes, “You weren’t meant to have a boss”. When everybody in the team know that they can influence a decision, and the best idea will win, everybody feels like they have a stake which is so empowering and motivating. Compare this to a job where the programmer has to simply translate a low level design document and is rewarded for conforming and not asking questions. Inevitably, the measure becomes on terms of Lines of Code or Number of Bugs Fixed per day.
Stand Ups, Team Retrospectives, Iteration planning meetings, each of these practices have their role in dismantling “command centers” if and when they creep up, even in flat structures.
I think almost all Waterfall projects that I worked on fell short on one parameter or the other - Quality, Timeliness, Cost, UX. The ones that didn’t, were the ones where we had a very capable client side Product Manager who worked closely with the team.
Customer collaboration is the key in ensuring that we deliver the product that the customer wants versus what we think the customer wants. Showcasing to customer frequently and getting feedback, dividing big requirements into smaller “stories”, all these help to stay on track.
Of course, all these things require an all-round, competent, multi-disciplinarian team to make it work and probably works best in smaller teams.
I have seen a lot of terrible code in the previous IT companies where most projects are won on price factors and this puts a lot of pressure during project delivery because the project cannot afford to bring in experienced developers. New developers starting their careers don’t have much to look up to and the code quality spirals downwards thanks to the Broken Windows Effect. The low margins also mean that the focus is to somehow get the project completed without thinking about code quality.
Having a maniacal focus on code quality, metrics integrated with CI, pairing, pair rotation etc. helps avoid this pitfall. Therefore, although the early milestones appear to have low velocity but the later releases will certainly be faster and on a strong foundation.