Principles of Software Development Productivity

There's been a few developer "Bill of Rights" lists that have floated around. These lists generally include creature comforts like dual monitors or a fast PCs. There's certainly a business case for fast PCs, and I've made more than my share of these business cases. But, these things are mostly just goodies under the guise of productivity gains.
I'm all for productivity gains—I personally hate wasting time on something that I don't need to do and doesn't add value. But, software designers can't simply use productivity as an excuse to get toys. If the productivity gains are impetus enough to get these things then we should always be focusing on how we can be productive in every aspect of our job. To that end, I've started keeping track of things that should be vital to every software designer's ability to do their job effectively and efficiently, in no particular order:

Unfettered Access to the Internet

There's way too much technology information for one person to keep in their head. I pride myself in being able to find almost anything on the Internet. If I don't know how to do something, I know I can find it on the Internet, absorb it and implement it. If I don't have access to the Internet, my productivity goes down.
This includes wholesale blocking of blog sites. Sure, many blog sites are full of chaff; but they all have useful development information on them somewhere; If I can't get on them then I can't get that information and I'm wasting the client's money.

Infrequent Non-development Meetings

I read somewhere that people who produce things (as opposed to people who manage other people) work in 4 hour chunks (people who manage people work in 1 hour chunks). If a 4 hour chunk of time is interrupted by a meeting, the productivity of that whole chunk of time is severely diminished, if not entirely lost. Having to attend a 1 hour meeting in the morning and a 1 hour meeting in the afternoon basically blows my productivity for the day out of the water. It sounds like it's just a benign 2 hours of my day; but the cost is really 7.5-8 hours. Not to mention, that's 2 hours I could be been doing something useful.

Meetings Must Have, and Abide By, an Agenda

It's seems obvious: how is anyone going to be productive in a meeting if they don't know the details and how to be prepared for the meeting? Without an agenda, attendees can't know what is out of scope. More importantly, how do the attendees decide when the meeting is done? They don't. Meetings without agendas go on and on and on. Without an agenda, the attendees don't know if they've discussed what needs to be discussed and they most certainly don't know if the meeting was successful or not.

Meetings need to add value, they need to accomplish things. The accomplishment of a meeting could be the fact that action items have been created to detail who, what, when, the priority, and possibly how, follow-up tasks need to be completed after the meeting.

Proactive Proliferation of Policy

Policies are great. If I need to do something or not do something, I'm more than happy to oblige. But, to inform me of those policies only after I've violated them does neither the organization nor me any good. I need to know about these policies before I get intrenced in work for an organization, and be kept informed of any changes to those polices. I can't take responsibility for abiding for them if I haven't been told about them or told how to read about them.
I once worked at a place that didn't give me a computer for the first week I was there. "Fine", I thought, I'll just use my laptop and get some work done. Well, there was a policy that no unauthorized computers could connect to the network. The net effect was that I was chastised for trying to get work done (if you meet me in person, buy me a beer and I'll be happy to tell you the details of the defined consequences of violating that policy and my experience).

People will find ways to get their job done and do them. If the ways they find to do their job violates some policy, they need to know so they don't do it.

Clear and Available Policies

Policies need to be clear and continuously available. If a policy is open for interpretation then it's easy to violate that policy. If it's hard for people to know they're violating policies, having the policy is pointless. If policies are spread by word-of-mouth, the essence and success criteria of the policy will get lost. Policies need to be documented and published somewhere where everyone can have immediate access to them.

Available and Responsive IT Support

We're designing and writing software for computers. These computers are connected to a network and to printers. If the computer, the network, the mail server, the printer, the intranet, etc. doesn't work, I can't do my job. I need to know who to talk to when I have a problem, and I need to to fix it as fast as possible. Me sitting around on my butt does me no good, and does the client no good.

This goes for all levels of IT. If the developers have to work with a SQL database but aren't empowered to be the DBAs then the organization needs to provide them available and responsive DBAs to support them. Having development work blocked waiting for a DBA to become available is not useful.

The corollary to this is that if an organization is going to schedule developers to work off-hours, they also need to schedule support for them in those time frames. Most off-hour work is a fall-out of scheduling problems. Having devs do work off-hours only for that work to be blocked because they can't get support is a waste of everyone's time and resources.

Clear, Complete, Unambiguous, Prioritized, and Verifiable Tasks.

Having to run around in circles frustrates me and produces nothing useful for the stakeholders and the client. I need to know exactly what I'm needed to do. If I don't know the whole story, I can't ensure I'm doing the right thing for what I do know about. I'm doing work for someone, I need to know what their priority is. If they don't tell me, I do it a random order or an order I feel is logical. A client can't tell me I'm not working on something of highest priority if they haven't given me their priorities. I also need to verify that I've done what was asked of me correctly. If a client doesn't tell me their success criteria I can't be successful: I will fail. That is, if I can't verify I succeeded then the alternative is that I've failed.

Immediate Access to a Subject Matter Expert

Having clear, complete, unambiguous, prioritized and verifiable tasks are a must; but if a client tells me those are all the requirements I'm going to tell them they are wrong. It's not possible for all requirements to be known up front. Technology changes, perceptions change and get clarified, priorities change, etc. Requirements change over time. I need to have access to the people who live and breathe the requirements: the subject matter experts. If requirements change, I need to talk to these people or I'm wasting client's money.

Clear and Approachable Requirements Engineering Process

Clear, complete, unambiguous, prioritized, and verifiable as possible. Mistakes happen, clarity is attained over time, requirements need to change. I need to know how to get those requirements changed and approved (telling me that there is no formal approval process is informing me of the requirements engineering process). Changes in requirements are usually high priority. If I have to waste my time trying to find out how to finalize or get approval for those changes, I'm wasting the organizations money.

Ownership of Schedule

This is a pet peeve of mine. It's not useful for someone to be told that they have x number of days to complete a task. They must be asked to estimate how long it will take for them to complete each task. No two people will complete the same task in the same amount of time when it comes to software development and design. There's two possible outcomes from telling someone how long they have to complete a task. One is they complete it on time–which means they most likely could have done it in less time and that extra time was squandered. Or two, they can't possibly complete it on time and everyone is setup for failure.

If schedules are being mandated on devs because they have a track record of poor estimates, then work with them to be better at estimating. Estimating work correctly is a rare trait; most people need guidance and experience in doing is correctly.

And don't pad estimates—that's fraud in my books. You need to account for all your time.

If you're a developer, make sure your organization isn't hindering your productivity by not realising these realities with you or your team. If you're managing or leading a team, be a good leader and empower you team members in these ways to make them more productive.

There's many more ways an organization can doom a software development process; but these are many basic errors that I've encountered. Have some others? Let me know in the comments.