The Primary Value of Software

I chose poorly.

My team has been pulling out stops all winter long to build a cutting edge single-page app for a very important client. Suddenly, earlier this month, the SPA framework I picked officially white-flagged it.

Yet, in spite of this and plenty of coffee, I sleep like a baby.

But isn’t this the nightmare scenario that our parents and managers warned us about when we started using open-source libraries? What if the sole proprietor of the project gets hit by a bus? What if the poor schlub making this thing for free wakes up and gets a real job? What if? They’re all going to laugh at you.

Oh, logic from 2007. Adorbs.

Of course I care about the app, and the long-term implications of the tools we choose for it. But I’m not uptight about having chosen the “wrong” SPA framework for our client because my team and I are clear on what really makes software valuable. And we work hard to ensure that our app has it.

What makes software valuable?

This is an idea that I picked up from “Uncle” Bob Martin’s phenomenal Clean Code series. It has changed the way I view my work, and I hope it does the same for you.

Ask just about anyone in our industry what gives software its value, and they’ll tell you its all about solving problems for users. And they would be right–solving problems makes the software valuable, and most folks who pay for software likely believe that this is the extent of what they are paying for.

But solving a problem that the user has today is the secondary value of software.

The primary value of software is that it is soft. That it is resilient in the face of inevitable change. That it not only meets the users’ requirements and solves their problems in the present tense, but that it can be readily adapted to meet needs that will arrive tomorrow, or the next day.

But this doesn’t just happen.

So, this is amazing news, right? Our software has a value we didn’t even know was there–let’s charge more for it!

Not so fast, there, Steve. This primary value thing is what makes software the bee’s knees, but it doesn’t occur naturally just because you’re writing some code. Most systems do not possess this quality.

What does it take, then? Planning for every possible permutation of our application’s future? Clairvoyance sufficient to pick the winning stack? Infinitely configurable options?

No, thank Turing. In order to unlock the primary value of software, the code from which it is built must be clean.

He’s doing it again

Man, I sure keep playing that clean code fiddle, don’t I?

And with good reason. It’s not because I am selfishly obsessed with the placement of brackets, spaces v. tabs, or the intricate contours of my navel, however engrossing each of those subjects may be. It’s not about preaching some esoteric set of nerd rules. It’s about long-term vs. short-term thinking.

Software Craftsmanship is ultimately about the value of software. Only clean code, code that respects the SOLID principles, code that is covered by tests in the way that only test-driven code can be, can stand up to change over time and truly yield this value. Whether that change comes from a shift in the nature of the users’ problem set or in the fickle wind that blows a new de facto standard library across our desks.

No warm milk for me, thanks

So we code clean and keep it clean. Our framework-y plumbing code depends on our valued domain logic, rather than our domain logic residing within framework-dependent code. And every new feature begins with a design conversation and one failing test at a time.

Between that and Good-Guy Eisenberg‘s generous plans for Durandal that make it more of a finished project than an abandoned one, my team is looking at a pretty nice-to-have problem in Angular taking the title.

So yeah, I’m getting my eight hours. Are you?

via Business 2 Community http://ift.tt/1nit8NP