From Pitch to Build
Developing software at an agency…
It starts with the business pitch. An RFP comes in, and we put together a crack team to whip up something to amaze and impress. BAM! We get the business, it's announced in the All Company Meeting, and everyone's excited. A project team is put together.
However, we switch from time and materials to fixed bid - leading to a boatload of assumptions in order to put the original RFP response together. Suddenly, 70% of those assumptions turn out to be untrue! What do we do?
What we should do is renegotiate, explain that the assumptions in the scope turned out to be false and either agree to deliver under the original terms - or increase the scope to include new terms.
Instead, we decide to work it in, and everyone immediately begins to feel the squeeze. "Part of the business," you say. "What's your point?"
When we get squeezed, "build it right" turns to "make it work quickly," usually because a) those we are interacting with don't care, and/or b) we don't particularly care. I want to address the latter, because the decisions you make as a developer are incredibly important.
Software construction is how you build software. It's the most expensive part of the projects you will work on.
How software is built has a profound impact on how long it takes to build - but more importantly, how long it takes to change. Here's why you should care.
1) Software always changes. Show me someone that built a project of decent size where nothing was changed and I'll show you someone that isn't being truthful.
2) Requirements go out of date. Sometimes the only documentation that exists is the code itself. If it's not human readable, it's not valuable.
3) It takes longer and costs more to slap stuff together. Though it may not seem like it at first (I mean, you got your prototype done in like 30 minutes!), assume it will change. Even if it doesn't, a published study found that minimizing coupling but increasing how closely operations were related resulted in 7x fewer errors and those errors were 20x less costly to fix.
On more than one occasion, I've seen someone in technology demonstrating something technical while a group of people *not* in tech were tuning out.
That's OK. Not everyone needs to know how things are made, but that doesn't excuse us from focusing on well-made software.
How to Get Started
Improve your code and productivity quickly in several ways:
- Inspect your code. Static analysis tools are great for this; we have a SonarQube server up and running 24/7. It's a good platform to consider as it supports most languages.
- Read up. Books like Code Complete and the Pragmatic Programmer are excellent starting points. You don't have to buy them, either! Check your local library; they're usually in stock - or you can get a Safari Books Online limited subscription by signing up with Mid-Continental Public Library (it's on the MO side but they have a partnership with JoCo public library. If you have a card at one you can get a card at the other).
- Test! Don't leave all the testing to QA. Save some back and forth by doing some of the testing yourself. Unit testing lowers the chance of introducing (and not catching) stupid errors considerably.
