Joel Spolsky has become something of a legend among the current generation of software developers. His common-sense, tell-it-like-it-is, experience-rich, narrative teachings have helped tens of thousands of followers to better software and better software organizations, since well before the great dot-bust.
If you're managing software projects and are not familiar with his ideas, you should be. Can you list six of the twelve questions on the Joel Test? No cheating, now! We can call this little meta-test the Djun Test. If you've failed, you would do well to schedule a day off, buy his book (Joel on Software - recently published by Apress), and have a quick read through. Don't stint with the highlighter, sticky bookmarks, marginal notes - research in 'brain-based learning' shows these will help you remember. And do the exercises.
Does this sound like work? Yes, it is. But here's an incentive. Not only will your software projects and team benefit, but you will be in a better position to get free money. Pretty much every country that can afford it has programs to fund technology innovation, since this is such an economic driver. If you are managing software projects and you're not intimately familiar the innovation incentives available to you, what's holding you back? Believe me, your competitors are already taking advantage of this.
Since I work in Canada, I'll focus on just one of the programmes available in here. If you are based elsewhere, you'll soon find the corresponding grants, tax credits, loans, or other funding mechanisms. The Canadian Scientific Research and Experimental Development investment tax credit, a.k.a. SR&ED, affectionately known as 'shred', refunds around half of qualified expenditures for properly managed research and development. For many small software companies, that's easily equal to profit from all other sources.
I can't blame you if your eyes are glazing over at this point - most people don't associate 'taxes' with 'incentive'. The good news, though, is that qualifying for SR&ED is really about good communication and effective process - something we already strive for in our software, and our business, and something we should be pretty good at as developers and software managers, right? And, since we're developing software and not better milking machines or pre-fab igloos, we have some pretty nice tools to help us.
Just for reference, here's the Joel test (you didn't peek here up in the second paragraph, did you?)
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
From my SR&ED perspective, here's what these are about:
- automation/repeatability (1, 2, 3, 4)
- monitoring/status snapshots (1, 2, 3, 4, 6, 7)
- reporting (1, 4, 7)
- planning (5, 6, 7)
- tracking (1, 2, 3, 4, 6, 7)
The trick is to integrate these tools to be able to support the following:
1. Answer the good old question 'who did what, when'. Specifically, you need to relate a given hour of work on a given date to an R&D outcome or objective. In any given project, some work will be routine, and other work will be "R&D". Being able to categorize this, in the moment it happens or retrospectively, and being able to substantiate this with reference to project plans, work products, and tracking records, is not only an essential reporting requirement, but very valuable for organizations in terms of tracking the R&D process, identifying outcomes of R&D, and tracking ROI on development work.
Here's one approach - arrange that all of your tools (source control, time-tracking, daily/continuous build systems, issue trackers, development e-mail lists, wikis, project management tools) generate an RSS feed. Aggregate these in one place. Presto, you now have a chronological, centralized view tracked back to source documents.
2. Provide a framework for narrative explaining the progress of R&D. For large projects, it might be appropriate to have monthly progress reports. Smaller projects might get by with quarterly reports. These should summarize and tie together information from time-tracking software, source control logs, bug-tracking logs, scheduling logs, spec changes, and other information sources to explain progress relative to a base (starting point) or with respect to a plan. In addition to explaining why a given project represents R&D, such documentation can often be re-used as technical marketing material, information for investors, legacy documents for archived projects, and in many other ways.
The key step here is to ensure that the source information is of high value. A few extra minutes with log entries for bug trackers, commit messages for source control systems, and so on, go a long way towards readable, narrative reports downstream. Joel is very persuasive in arguing for holding developers (and I'd argue, everyone on the team) to a high standard of writing. The next step is to ensure that the value in this communication is not lost in write-only data stores.
There's lots of other aspects to this intersection of technology, process and craft. For example, Joel does not address with his test the important matter of communication within a team, and how information discoverability can make or break a project. Another question which could easily be added to the Joel test, if thirteen were not such an unlucky number, is "Do you use a Wiki for communication within your team, and with your user community?"
But that's a story for another day.