Intelligent Software Building: products, platforms, programs

On a regular basis I see folks who are trapped by the siren song of reusable code.

Now, don't get me wrong.  Reusing code is a wonderful thing, and it's a good goal, but it's important not to get carried away.  There are basically three levels of reuse:

1. Programs - this is when you reuse parts of your own code, on a personal sort of level.  You built these routines and snippets, documented them and like them.  They're something you've done before and know you want to do again, so you were kind and thoughtful to yourself and wrote it in a way that you would recognize.

2. Platforms - this is when you specifically plan for reuse when you're writing something.  Platforms refer to a broad area of capability that is important and that you'll want to build on.  Platforms require serious forethought.  They also require serious documentation and some support.  Typically this is something you will share with other members of your team.

3. Products - this refers to a software platform that you want to make broadly available.  When you create a software product you absolutely have to have clear documentation in and out of your code.  You have to plan for wide deployment and you have to have support people in place.  When changes are made, you have to have a thorough test apparatus in place to understand what the impact of your changes will be on others who have built their software with your product.

especially to yourself...

Be kind to the person who will inherit your code, because often that person is you. 

Many times I have cursed the me of weeks or months ago for leaving a mess for me.  When I'm kind to me, I always appreciate it.  Reuse of your programs is just good practice, and naturally happens when you're writing thoughtful and clean.

After you've experienced those benefits a few times, you'll start dabbling around with platform style reuse.  You'll think "hey!  that little block of code has been so useful to me, I bet others would like it!"  Before you know it, you have a whole set of interconnected things that you've put together and share.  You probably don't have any sort of obligation to support it, but it's fun and you're supporting your own work through the thing anyway, so it just makes sense. 

Ain't nothin' wrong with Platform style reuse.

Where you have to think long and hard is around the Product-style reuse.  This makes sense if your goal is to sell this code as a development tool.  This is something like D3, or Telerik, or the Unreal Engine, or Havok or anything like that.  More often than not, I see this when developers fall in love with their own, potentially reusable programs, assemble them into a platform and then decide the whole world needs it.  You will have tons of support work to do.  You will have to maintain forward and reverse compatibility.  

If this is some sort of exercise in self-love, you need to stop now and slowly back away.  Really, unless you're planning on making enough revenue from this (or if internal facing, saving enough effort) to justify several developers and a testing team, this is just a bad idea.

Sometimes a platform may naturally find demand in the market.  Maybe the platform you built is truly wonderful and well documented and bullet-proof and you really really want everybody talking about how awesome you are... Even then, don't do it unless you have the support staff.  The first time some package you're including gets depricated or MS rolls off some capability you're counting on or any other of a million possible things, you're going to have all those people who were singing your praises on your IM, demanding immediate fixes...

software III

Don't pee your pants for nobody

This one is pretty similar to the "you'll regret the hack" thing, and I see this a lot with green developers.  With deadlines looming and a rush to get things done, you may be tempted to degrade your work from "software product" to "proof of concept".  What this means is that you're no longer building a software platform you can add to later, instead you're building specific features to try and get somebody off your back.  It works out a lot like the old metaphor about peeing your pants for warmth.

you're warm for a while, anyway...

Essentially, you solve your short-term problem but wind up with a bigger, long-term problem.  This is bad when it's a team decision, and even worse when a developer does this without telling anybody.  I've personally been in the situation where one of my developers did this sort of thing and I wasn't close enough or careful enough to know that's what was happening.  Once we got past UAT (user acceptance testing) and I started rattling off the next steps and new features to add, he turned defensive and told me he needed a few months to rework everything because everything he had just done was purpose built to get past that first deadline.  He literally set us back 6 months and absolutely destroyed my trust in him.

Hire fast, check-in faster, fire fastest

Back in the games days I had an employment model that was built around the fact that I had no idea how to hire people.  In retrospect, I was probably ahead of my time, since research seems to indicate that interviewing is almost worthless, GPA is a poor predictor of work performance, and things like pedigree and credentials are over-rated.  This was before I had ever heard of a behavioral inteview, much less experiened or conducted one.  Since I worked in computer games, every job opening I had was flooded with candidates, and often these candidates were non-traditional.  They were often wiz-kids with no college or formal training.  Sometimes they were older folks with a passion for gaming.  Some were hobbyists who wanted some extra income (that was fine, I had plenty of contract-work jobs available, too).  The hard part wasn't finding people, the hard part was knowing which ones I could count on.

This was especially important for my projects with really short timelines and really tight budgets.  One really flaky developer could derail the entire project (and with it the budget and with the budget my paycheck for weeks or months).

The approach I came up with was "Hire fast, check in faster, fire fastest".

I googled "you're fired" and somehow this image came up.  It somehow seems better than anything else I could have put here.

Basically, I gave a job to anybody who wanted one.  Every new employee would get a single work product to deliver and two weeks to deliver it.  The work product was always something I actually needed and something that I knew could be done in two weeks.  Anybody who didn't get the work done on time was fired.  No questions asked, no conversation, no excuses.  What I had learned was that anybody who is willing to flub their very first impression will continue to disappoint thereafter.  Honestly, this got rid of around 80% of the people I hired.

I've applied this rule in a general sense in many ways since.  If I'm looking to hire a painter and he shows up late to discuss the quote, I take him out of the running.  I once had a buddy ask me to help him find a contractor to build a block wall around his house.  The guy showed up 30 minutes late and I told my friend not to hire him.  My friend did anyway and since I'm telling this story here, I'm sure you can imagine he never got his wall.

Hit the easy problems first

There's the rule when you're playing pool.  When one of your balls is sitting right on the pocket, you don't shoot that shot.  It will probably get knocked in on its own and you're really just wasting a shot.  That mindset is completely misplaced here.

a tempting but misleading metaphor!

Really this is probably just a good project management thing.  If you leave the little problems until they end, nothing good can come of it.  If they really are little, you'll just have a shit-ton of little problems to sort through and fatigue will build.  If any of them turn out not to be little problems (and some of them will end up a lot bigger than you originally thought) you suddenly have big problems that you weren't expecting, popping up right at the end of your project, when you don't have time to course-correct effectively.

Do those little, easy-looking things as early as you can.  Sprinkling in small wins helps to keep you from getting worn down on big projects.  Also, it gives you the chance to adjust your timelines or features if you wind up facing some big, unforeseen shitshow!

this thing again