Software Development “Lessons Learned”

My organization just released V1 of our new procurement system. The product is quite massive and we still have a long ways to go, but it feels great to have a working solution end-to-end in production. The actual development time was 33 2 week sprints. We started out with a small team of 5 people, and are now running 3 full teams consisting of 26 devs/testers, 2 scrum masters and a product owner.

As the initial person on the product I’ve had quite the learning opportunity, and wanted to take a minute to share some of these tips or ‘Lessons Learned’.

 

Process

• Get a process and stick with it. Iterative/Agile is superior in my opinion, but its relative to your type of work
• Get training for your team/organization on the process you choose, no really, GET TRAINING! (we used fellow Elegant Coder David Starr for Agile training with a focus on SCRUM and Lean implementations)

Vision

• The Product Owner is the single most important role. Crap in crap out. Not understanding your customer causes rework, rework destroys ROI, rework makes everybody involved unhappy
• Too many opinions can be detrimental to the product. You must have a final say, even if only to get some traction so you can revisit the results
• Being creative is great, but it can be a problem if there is too much of it. I suggest you join a band or put some stickers on your laptop if your the cowboy that must always express himself

Team

• A good blend of skills works well and makes a cohesive team. Passion,  experience, consistency, creativity, aptitude, domain knowledge, humor or just freaking smart, everybody brings something different. There is no one person that can do it all, you will need some of each
• Mix generalists and specialists, shoot for vertical teams than can deliver complete slices of functionality. Specialty teams do not work. (DB, UI, Etc)
• Community involvement. The community can be an extension of your team, I have learned more from the community than anywhere else. Encourage blogging, conferences, user groups, social networking
• Pair programming is the best way to cross train on technology and disseminate domain knowledge through your team(s)
• Have fun with your team. Joke, laugh and try to keep it light

Work Environment

• Co located teams, open team rooms or bull pens
• Communication is the key. Emails with "ill get back to you tomorrow" wont cut it. At any time, you should be able to turn to someone and ask "Hey, what do you think about foo?", "Can you do a code review?", "WTF does that last code you checked in do?" or "Can you pair with me through this service’?
• The last thing you want is ‘A hero in training’ sitting in their ‘cube silo’ pounding out mountains of code by themselves with no team involvement
• Tear down those cube walls

Healthy Code Base

• Standardization: Coding standards, FXCop, Code reviews, Test coverage
• We pride ourselves on the fact that its very hard to tell who wrote a piece of code
• Continuous Integration: You should always have a working product. If the build breaks, the production line must stop
• Keep your code clean! Remove unused code, fix ignored tests, comment WTF’s, format your source files. No Broken Windows!

Testing

• I cant stress Unit & Automation testing enough
• If you can’t refactor easily, you are screwed. *read last statement 3 times*
• If you are scared to change a piece of code out of fear you will break something else, this is a sign you are heading towards entropy
• Tests provide regression across your code base allowing change to safely occur
• Use BDD/TDD as a design process. How can you code something of quality if you don’t know what you are going to code yet?
• Testing makes you consume the code, thus, interfaces naturally become "intention revealing"

Commitment

• Developing software is hard, push through it
• “When you come to the end of your rope, tie a knot and hang on” – Franklin D Roosevelt