The Hookup

My background for the last 27 years has been application systems development and integration. I have played every role from business analyst to developer to architect to project manager to team leader to director at one time or another. I know what gets application development teams motivated and excited about their job. I know what causes them to break down. I know what the distractions are and the inhibitors to effectiveness and efficiency. I also know the ROI on solving some of these problems.

Number 1 cheap answer to make software wonks happy and productive – The Hook Up.

They want the fastest workstation, the best software tools, the best technical environment and the most control over their own destiny that they can get.

When software developers are fighting against the toolset that they are using to build the software, and it’s inherent limitations, they are much less effective and efficient. Tools are cheap compared to devs – so we need to grow up and get over it.

Payback

If I pay (gross) $100 per hour for a senior developer and he spends 2-3 hours a day waiting for the software to build, the test suite to run, or some other toolage related activity to complete, I am blowing 25-40 percent of his productivity out the window. At $100 per hour – a $3k workstation (fully loaded with installation cost) would pay for itself in a month.

If 5 developers on a team spend an average of 5-10 hours per week on merging code because the software configuration management software isn’t very smart and I could cut that in half by moving to a new version control tool – what is the payback?

Why Don’t We?

If every developer could get 1 to 2 hours per day from a refactoring editor, a merge tool, a macro-enabled editor or whatever magic beans will make the developer more efficient – why would we not do it? If a developer could get 1 to 2 hours per day from a 6 core box with 8 GB ram and dual 23 inch monitors, why wouldn’t we do it?

If we could get our whole team to be 50% more effective by writing unit tests before writing the actual code that is deployable, why don’t we do it?

Because!

As far as I can tell, there are exactly 3 answers:

1) Unity – you can’t get two developers (let alone a large team) to agree on a tool set. So the prevailing feeling among management tends toward – if you can’t even agree amongst yourselves, why should I do anything.
2) Disbelief – unless you wrestle with software development tools, you may not realize how much wasted time there can be just fiddling with tooling to get things done.
3) Fear – fear that spending the money on tools will not produce a result, fear that spending the money and time on tools and practices will be noticeable to superiors who share the fear and disbelief, and finally fear of things that are not well understood – development managers used to be developers back in the day – but the further away from the day to day coding work they get, the less they know about current tools and practices – that breeds fear of things I don’t understand.

The Solution

We all understand that most of the cost of software development comes from human effort – developers. Why on earth would we not seek to make them as efficient as possible? Why are we not trying to reduce cost (capital outlay) by making development teams more effective and efficient? As managers of software development teams, we should be advocating everything our teams need in terms of staff and practices and tooling.

As the manager, you have to create the unity by listening to your developers and bringing consensus on practices and then defining a road map for solving tooling issues – what tooling problem is most important, to least. You can defeat your own disbelief by a) getting back into the code, and b) having your developers demonstrate the process improvement a better tool can provide. The fear itself will subside when you begin to actually realize material benefits from implementing better practices and tools. You can start slow, and measure improvements and build some case studies. When you have some proof, you can go to your management to say – we can do better with a modest investment.

The hard part for us (especially those of us who have not written code in a while) is to deeply grok the problems in the modern software development process, and to have those problems resonate in ways that allow us to help form solutions.