Posts
1150
Comments
891
Trackbacks
1
Important Lessons in Software Development

Nate Kohari of AgileZen fame (disclaimer: I am a paying subscriber of AgileZen, I think it’s good, not sure I’d call it great, though I use it more lightly than intended, I think) has a post where he talks about the experience of starting up the company (which has since been acquired by Rally Software).  It’s a good read overall, but I particularly agree with two points he makes:

“I built AgileZen unlike any other piece of software I’d built. I cut corners that I would never have thought of cutting if I was working a day job. And you know what? It didn’t matter. We launched on schedule, we crushed our user and revenue goals, and our customers raved about the usability of the product. No one gave a shit about what our test coverage numbers were. Our software made their job or life easier, and that’s why they bought it…Now, I’m not saying every product should be built this way, but it certainly shifted my perspective on what’s vital and what’s not when building software.”

“After we launched, I spent the month of October basically rewriting every line of JavaScript in the app to create a more maintainable structure. Was it wasteful to throw so much code away? Maybe, but we were up and running, and we were making money. Before we could afford to spend a lot of time to make the software maintainable, we first had to prove that we would actually have to maintain it — we had to make sure that we actually had a market. Your app can have the best architecture and be 100% defect-free, but if no one cares what it does, it’s wasted effort.”

Though it’s been forever, I do remember being part of a startup, and the constant “we have to launch on time, we have to launch on time” of it all (we launched two weeks late, and I missed it because after a 36 hour straight work shift, I was dead).  We thought (rightly) that we were in competition with some other groups and we had to get launched and start making money and all that (at one point months or years later, our then CEO’s constant mantra was “we are the clear market leader” which I think we were for a bit.  Till the funding ran out.  Our main competition still exists, generates two billion dollars a year in revenue, I think.  Surprisingly, I’m not the bitter one amongst the ex-colleagues.  But I digress)).

I have my own company which could be startup-y, but I think some lessons can be learned that applies to most software development. 

What value does your software provide?

It could be to external customers or internal users, but in most instances, you can tie the reason for the existence of your software to someone it provides value to.  And that’s the most important thing.  Maintainability, separation of concerns, testability, yada yada yada, all that matters.  Especially to developers.  I like my SpecFlow features very much.  But they don’t matter if the interfere with the value of your software.  This is why, when I think it interferes with that value (I want to say “value proposition” but then I’d have to shoot myself), I don’t write a feature.  In other words, I make a judgment call.  What is the estimated cost of not having a feature covering some functionality?  What am I giving up?  I’m giving up ‘code coverage’ (though not in the strict sense).  But some features are made to be used to help drive development, and then *thrown away*.  At times, it is still better to create the throw away feature, but not always.

Some people of the Software Kraftsmen BrownShirt Squad (trademark pending) ilk like to argue something like the following: when you deviate from the strict maintainability path, you are taking on technical debt, and it will end up costing you more in the end.  There’s a reason why they like to argue something like that: a helluva lot of time, that argument is absolutely compelling.  You will end up block providing value down the road.  And we’ve all been there, facing the dread of changing some unmaintainable ball of mud where you fix/upgrade one thing, and break one or three or twelve other things.  And that sucks.

But, it won’t always block value.  Where the SKBSS argument goes awry is completely ignoring the fundamental truth of YAGNI, and creating a local optimization that prioritizes developer ‘friction-free’ warm fuzzies over value.  It isn’t just me, but my experience is that there’s a good bit of software out there that gets written, and then it is done.  A significant amount of work that I’ve done involves ETL projects, and so it’s probably a bit more natural to find this in this area.  In an ETL project, there are times when you need to rigorously test out code, but most of the time, what really matters is that the data (usually large amounts of it) ends up where it ends up when it is supposed to, and for that, you run the code that does the ETL.  Not test code that tests out certain pieces under mocked out conditions, the actual code.

This extends beyond ETL projects though.  I don’t know that you can put a hard and fast rule on it, but some pieces of software are designed to be written, and then left alone.  What ultimately matters is that it works and provides value, even if the code behind it is objectively poorly maintainable (and though I have argued about the meaning of ‘maintainability’ in the past, I’ll accept the meaning that most people mean by it for the point of discussion).

*Even if* future value will be blocked, it is sometimes the right decision to provide the value that you need right now *right now*, knowing full well you will pay a price down the road.  To go along with the analogy, debt is sometimes inherently useful, and used by businesses all the time.  It (should be) is a business decision to decide to take it on or not.

Another lesson

See previous discussion.

Any number of people who have been consultants can relate to this (I think): I’ve recently been handed one of those ‘gifts that keep on giving’ in software development, a Very Important ™ project where the original lead developer and lead project manager left the company the day after it went into production.  Fantastic.  I will let you guess whether it worked the day after it went into production.

From a maintainability standpoint, the thing is a significant improvement over what it is replacing.  Grading it very strictly, on a scale of 1 to 10, I would give it about a 5.  Not spectacular, by any means.  There are core components to the thing that I’ve been able to fix significant issues or add decent functionality in the space of an hour.  There are other parts of it that, frankly, I’m not touching unless they order to me to (also known as the prioritization process).  Given that the previous software, graded very strictly on a scale of 1 to 10, was about a –3 (I’ll leave you with two words, “Control-M” and “VBscript”), it’s a definite improvement.

But the end users don’t care about that, they care that it hasn’t been providing all of the value that they thought they were getting (the reasons for this are worthy of another post).  Because I’ve been able to make fixes and add some value, the maintainability of the code base has been a plus.  But they, and I, would have preferred it provided the value originally expected, even if it was a maintenance dog.

Summary

Becoming a better developer involves learning all of those yada yada yada things I mentioned before.  If you learn them, you will be a better developer.  But being an even better developer involves learning when the yada yada yada things can and should be put aside.  This is why manifestos are bad, and why you should strive to be a craftsman without becoming a Kraftsman.

posted on Thursday, September 09, 2010 9:35 PM Print
Comments
No comments posted yet.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 7 and 7 and type the answer here: