Productivity

Let's just dive straight in. Firstly you may be wondering about the url 'ADIWS' - well I'll tell you. I recently attended the Gartner summit Application development, Integration, and Web Services (ADIWS) here in Sydney. The content and speakers seemed a little disappointing at the time, but I've since been mulling over the presentations and decided to get some thoughts down on paper (or what passes for paper these days), hence this blog with a dodgy URL.
There was a lot of talk about corporate IT dev budgets being reduced, but corporate expectations for IT delivery increasing - i.e. business is demanding improved productivity from its development resources. It started me thinking about all the ways to improve productivity, here's my list (I'll expand on it more later). They fall into two main categories: a) do things more efficiently, and b) increase reuse.

1. Get coders coding faster, or more generally 'get your workers working faster'. Work, hardware, and software environments all play their part here. To some extent this is the dev tool providers' 'promise' - e.g. MS have always tried to differentiate VS with productivity features (e.g. intellisense), but they've also realised that coders aren't their only market - VS2005 will provide 'license streams' for testers and architects. We're also seeing more and more developers with dual screen monitors...
2. Perform less rework (=write fewer bugs). TDD is gaining momentum, and seems like a good solution to the problem of buggy code. If the code passes the tests it has no bugs, so keep going until they pass. What could be simpler? Oh - there's the slight problem that the developer writes the tests to code against, so this needs to be adopted with care.
3. Create the right software. I've seen plenty of custom code written (some of it even exactly to spec) that has not met the requirements of the business. What's the cause? Poor analysis? Wrong methodology? No prototyping? Fickle users? No business plan? I have my own ideas - what are yours?
4. Automate where possible. There's a few candidates here - the obvious ones like code generation of data layer or O-R mapping code, the regular build process, any project-independent, repetitive task (e.g. capturing code metrics), and laborious, high risk, manual work, even if performed infrequently should be automated (e.g. production deployments)
5. Spend more time producing working code. The software is the end product of our efforts so lets spend more time producing it and less time on setting up machines, searching for printer paper, creating / reading useless documentation, trying to squeeze requirements out of a user over the phone, setting up test data, writing a blog. This relates to one of the principles of the Agile Manifesto: 'Working software over comprehensive documentation'
6. Have a corporate IT plan. I've seen plenty of projects deliver 'interim-ware'. The dev team was promised that it would be replaced in 6 months when the Peoplesoft roll-out went ahead, but four years later the interim-ware code is still there as undocumented and poorly maintained as ever - oh and with lots of extra functionality because the Peoplesoft implementation was cancelled... With a company wide plan, informed decisions can be made about how much effort to expend on disposable software, or ideally avoid this development work altogether.
7. Use the DRY* principle at a company level. I can't count the number of security / permission schemes, code, and screens I've seen created from scratch - even for the same company. I'm not saying I'm a fan of cut and paste coding - but even this is actually better than repeating work that's already been done. Of course there are better ways to avoid repetition.
8. Use consistent integration methods. On the occasions when systems are integrated, the developers of each system get together for the interface debate - normally a battle of wills regarding developers skills, preferences, division of work, etc, the final agreement often looks like no other interface the company has developed. Standards of system integration efforts are required at the corporate level. You never know, with proper planning you may be re-using some of the interfaces later.

Feel free to post any comments.

*DRY---Don't Repeat Yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system [or enterprise?]. From the Pragmatic Programmer.