DevOps Zone is brought to you in partnership with:

Cody Powell (@codypo) is the cofounder and CTO of Famigo. Famigo's main offering is a cross-platform recommendation engine for mobile content, helping families find things like the best android apps, best iPad apps, and free apps. He's a graduate of Trinity University, an ardent supporter of the Texas Rangers, and he makes a mean mojito. Cody is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

How Shipping Software Teaches You to Make Tough Choices

  • submit to reddit

Several years ago, I had a job that seemed like heaven. We were a new team building a new product. We were using new technology: C# 2.0 (yes, people were once excited about major releases of C#). We were using new techniques, like scrum and test-driven development. It was greenfield development in every possible sense, except for the one where our desks would actually be situated in a green field.

I lived in this environment for a few years. I learned a lot about software development, technical leadership, and how to build big systems. Ultimately, though, I think I wasted those years. Why?  We never shipped.

Something magical happens when you ship software: your decisions suddenly have consequences. You suddenly must consider trade-offs. Hopefully, people suddenly care. If they don't, you suddenly must correct that.

What's the big deal about decisions and consequences? Any fool with a text editor can write code, but only an amazing few can code and make good choices around trade-offs. That's the most valuable skill a developer can possess: the ability to make hard decisions. (That's actually a great way to make career choices: opt for the place that'll let you make harder decisions.) Like riding a bike or juggling chainsaws, the only way to get good at making hard decisions is by doing it a lot.  Each time you make one of these decisions, gather data and iterate accordingly.

When I was working on that project that never shipped, I felt like I was making hard decisions. We had big meetings and loud arguments about things that seemed important at the time. You can bet your sweet bippy that we came to conclusions on all sorts of things. However, since we never shipped, we never got any data about any of the choices we made around things like architecture, code coverage, implementation decisions, featureset, and user interface. Without that data, we had no way of knowing if we had chosen correctly. Did we get better at making hard decisions?  Without users, how could you tell?

There was an easy solution to the problem I faced at that job: ship the dang thing. That decision wasn't up to me, so I should've done the next best thing: join a different team, one that shipped a ton of code. Even if the codebase is worse and the product is less interesting, find a role where you ship; it's the only way you get better.

Published at DZone with permission of Cody Powell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Luca Cavagnoli replied on Wed, 2013/03/20 - 6:24am

 But aren't you supposed to deliver something at the end of every iteration in scrum?

Bimal Tandel replied on Sun, 2013/03/24 - 9:58am in response to: Luca Cavagnoli

What would you deliver by end of the sprint or an iteration is a testable feature. Making your product generally available to others require more than completing a planned feature. Most organizations have a release criteria beyond just being feature complete.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.