Don’t let the shiny title fool you… I am a developer at heart and this article is for managers who want to improve the lives of developers and make projects more likely to succeed.
Assumption: Your definition of a successful project matches mine. ‘A successful project ends on time, on budget and produces software that meets the user’s needs and wants’.
So how do you make great software fast?
Cut out all documentation and up front design and keep your initial feature list small. How small? Small enough to build in a week (more on that later). The only documentation you will need is a reference document describing your technology stack and development environment so you can easily set up new developers or recover quickly from hardware failures. In lieu of design documents, use meaningful and descriptive comments and names in the code. Err on the side of being too verbose and write them with great empathy for your fellow developers who will work with your code. This information is more effective because it is located when and where it is needed most. It is more likely to be helpful and kept up to date than a Word doc on a network drive. Why keep the feature list small? To keep design scope small. Design at any scale has assumptions built in. Large design scope equals large assumptions equals large code re-writes. Keep the scope small.
Do not re-invent the wheel
Unless you are writing code for NASA or the NSA, someone has already solved parts of your problem. Look for open source solutions to as many of your problems as possible. It will be cheaper to build and support. The open source solutions you pick should be widely adopted with an active developer community. For example – Hubba has an analytics component. Instead of building an analytics module from scratch we are integrating Hadoop and Mahout. Check out SourceForge and GitHub to find suitable matches to your problems.
Keep the development team small
No matter how great the individual developers are, as soon as there are too many, overall velocity goes down. Everything takes longer – code merging, figuring out who broke a build, planning the current week’s sprint, discussing integration and design issues, interpersonal issues and all manner of communication. Based on personal experience the magic number is 5 developers. A team bigger than this should be broken up and given separate projects to work on. A key benefit of a team of five is there’s nowhere for poor performers to hide.
Replace meetings with ad hoc instant collaboration
At Hubba we have 30 minute meetings 3 times a week. That’s it. No more – no less. And they happen at specific appointed times that do not change. The result is large blocks of uninterrupted development time and a fixed weekly meeting schedule developers can plan their activities around ahead of time.
Most of the communication that results in good code is ad hoc collaboration anyways – not meetings. A team of five can fit around a reasonable sized table that makes instant ad hoc collaboration possible. Questions are asked and answered instantly. Design decisions are hashed out without booking a meeting room and hunting down the participants.
Release working versions of the system at least once a week
I’m going to use ‘Agile’ lingo for this section because it’s a familiar way to describe what I’m talking about but you can call it ‘Lean’, ‘XP’, ‘Macaroni ‘n Cheese’ … it doesn’t matter. It doesn’t even matter how you do it. Just do it. Deliver working software at the end of each week.
Weekly releases of working software allows real users to give corrective feedback before more incorrect code is written. This reduces the total amount of refactoring necessary over the life of the project. It also forces the team to develop the UI and the backing logic concurrently. This technique is effective at exposing incorrect assumptions. Corrective action can then be taken mid-sprint. The weekly release cycle allows the team to focus on the design of the current week’s work. There’s no time to do more. This is not to say you shouldn’t think about big picture issues like security – just don’t get into the detailed design until its time to start coding those features. Even the biggest complex modules can be built piece by piece.
Finally, the most important reason for weekly releases; acceleration. With each sprint the API within the system emerges and becomes increasingly stable. Features that were unclear in earlier sprints become clearly understood. New technology implemented in earlier sprints are now familiar and easy to use. Defect rates fall and velocity rises.
A hugely under-rated side effect of delivering working software weekly is the sense of accomplishment. Good developers are proud of their work and want it to see the light of day. Giving them the chance to do this weekly is an incredibly strong and healthy motivator. Poor morale results in poor quality code.
Test Early, Test Often, Test, Test, Test
I’m not going to get into the ‘write-tests-first’ debate because I don’t think it matters. Many developers I respect develop their test cases before the application code. Personally, I write my tests after. In the end it does not matter as long as you are writing enough good tests, testing early and testing throughout the sprint as frequently as possible. This is the reason for automating the tests. Test, test, test.
Granularity of tests is less important than test coverage. Coarse-grained tests that cover 100% of the system is fine at the beginning. When you find a defect, write a test so it can be caught easily next time. Over time the areas of the system that are most likely to break will have the most fine-grained tests.
Manual integration testing is a must. Luckily, the weekly release cycle makes this feasible since only a few new features can be added per week. Automating GUI testing in the early stages is pointless since the UI changes so dramatically and frequently.
Test, test, test.
The Secret Ingredient
There is no secret ingredient. Making great software fast is hard work. My advice is to give your teams a fighting chance by removing all the obstacles that prevent good code from being written.
What has or hasn’t worked well for your teams? Share your comment with our community.