Does building software feel like walking through waist-deep molasses?

Delivering value shouldn’t feel hard.

You’re the manager of a .NET Software Project team. You have a software team with a deadline, and you’re not sure why the pace of software delivery seem slower than you’re expecting.

Your team builds software and your stakeholder changes their mind, but because of decisions made early in the project, the system is harder to change than you need it to be.

Your team spends time every project on a “Sprint 0” to figure out what technologies to use, and those decisions have ramifications throughout the project.

Your stakeholders ask you when they’ll be able to give feedback on features, and you have to tell them “Soon”, instead of “Right now”.

Your team fights bugs that crop up as the deadlines get closer, and deadlines are in jeopardy.

For you, “Code Freeze” is a phrase you know all to well as the most viable way to de-risk delivery of your software project, to not let bugs get in too close to the release date.

It doesn’t have to be this way.

I believe we’re in the dark ages of software productivity. We’re surrounded by tools that claim to increase our productivity, yet we’re delivering software at the same rate we were 20 years ago and we’re even unhappier with our tools today than we were 20 years ago.  Executives wonder why their software teams aren’t delivering as fast as they need to, and software teams wonder if Executives ‘get it’.

Even though software has changed the world, we’re still building software the same way we were 20 years ago. We look for process improvements without looking at how we’re building software.

I believe we can build better software, faster.  I believe adopting Test Driven Development can change how we build software. I believe it allows us to build better software, faster. I believe it allows our software projects to reflect the needs our businesses and stakeholders have: To get the features stakeholders want, and demonstrate how the system works as quickly as possible.

I believe through Test Driven Development, we can double productivity in some cases. This isn’t a pipe dream — it’s possible right now.

I’ve been a software developer for 20 years, and worked in teams of all shapes and sizes.  I cut my teeth on Perl, a gloriously productive language that is still useful today. I moved to developing large-scale web-based software for a variety of industries, from AOL’s Daily Finance, to the Portfolio Management product from The Motley Fool,
to managing infrastructure and SQL Server Databases for the white-label community engagement software for non-profits, to writing firmware for Jewelbots. Most recently I was responsible for building the software and team for ITPIE, a network management product that allows engineers to manage tens of thousands of network devices across a heterogeneous network. Now, I’m focusing on my passion: helping software teams double their productivity. I’m not stopping until the software we use to build software reflects how we work and is optimized for delivering software quickly.

Interested in doubling your team’s productivity? Contact me for a free consultation to get started.