Mutual Admiration Society

Be careful what you hear, it may not have been what was said (or what was meant).

I just finished Malcolm Gladwell's wonderful podcast series "Revisionist History".  There are many interesting threads through the various episodes, but the big meta-theme that loomed large for me was the danger of confirmation bias.  I think it was the second episode  (the one about Saigon) that really hit on the issue.  It is worth the listen.

This problem is giant when you're building a business model.  It is very hard to keep somebody in the room who honestly thinks your idea is stupid, but that person is essential.  I'm not talking about some devil's advocate who will throw out half-baked objections before rolling over and giving you a false sense of accomplishment.  I mean somebody who really thinks the idea won't work and is willing to try hard to articulate why.

"Oh, you're so smart and your new business idea can't fail!"

What comes naturally is that you will find somebody else who is enthusiastic about your idea and will be supportive.  Often this is somebody you already know, and probably you're on friendly terms. After all, that's why you brought the idea to her in the first place.  She'll talk up how great your idea is and you'll recognize what a genius she is for liking your idea.  The two of you will add more friends until you've built up a real, proper mutual admiration society around self-love as represented in lavish praise for one another's brilliance.

"We're all so smart and funny and we're all going to be super-successful!!"

This is great when you're starting out!  Everybody except the most ruthlessly anti-social people need external approval of some kind.  The trick is knowing when it is time to stop bolstering your confidence and adding good news and start sorting out the potential problems, doing your pre-mortems with serious abandon and sorting out the real contingency plans.

At that point, it's essential to realize that sometimes the smartest people in the room are the ones who are willing to say "I don't get it" and your best friends are the ones who are willing to say "that's stupid."

Management Fail!

A developer in my org came to me with a technical question she was working on puzzling out around something we call "Decision Units" in portfolio.  Decision units itself is a topic worth its own post, and not really important here, but the gist of it boiled down to this:

Her: "We have a problem handling decision units that exist in multiple business units, where analysts in different groups aren't aware of all of the logic relationships that might exist for that project."

Me: "What's the problem?"

Her: "Well, the way we're handling things right now, if anybody makes a change to the logical relationships for a given project --if they add a dependency or some sort of optional relationship or anything-- it will wipe out all the stored values for that project.  Worse yet, the analyst who loaded them before won't know they were wiped out, and when they go back to load them again, there will be a bunch of new alternatives there that they never heard of!"

Me: "That is a problem!  What do you think we can do about it?"

She gave me a good explanation of the issue that indicated she understood both the technical character of the problem and the business character of the problem. 

She really had her head around the thing.  She then delivered a very technical, possible solution that involved setting some flags and having users determine several things in advance and some other business rules around the process flow.

Me: "I think we can do something simpler.  Here's what I think..."

And then I went on to sort of brainstorm out a couple of default states and business rules that eliminated most of the possible sources of trouble.  Lastly, I sketched out an approach that would handle the last situations elegantly and simply and without requiring the users to do anything they weren't already doing.

Her: "Wow! That was really great!  I'm glad I came to you.  Here I was, thinking of something super-complicated and all I needed was to talk to you and you had a simple answer right away!  Thanks!"

I felt pretty good about myself for a few minutes and then realized I had totally failed her as a manager.

With a little coaching I'm pretty sure that she could have come with the answer on her own.  Maybe a few questions, or at the very least I could have structured the conversation more collaboratively.  I sort of pontificated how I think it should work and we were done.  My developer was left maybe feeling good about my skills, but probably a little less confident in her own.  That's a big fail as a manager.

this is a clever metaphor!

I think this sort of thing is why it's very hard for managers to make those "Career Pipeline" transitions from independent contributor (IC) to manager.  We build up these technical skills and are rewarded for them, and often they become a source of pride and self-worth.  When problems come along that are in the sweet spot, we think immediately of a fix.  We miss the chance to do our new job, which is coach the person bringing the problem as they figure out a fix.

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

software development II

You will always regret the hack

Every project gets hairy at some point.  Deadlines start to loom, customer requirements start to tighten, subcontractors and ingredient suppliers are late or flake out entirely.  The team gets stressed and the iron triangle reminds you of its immutable force:

the ol' iron triangle

Adding resources at this point never works.  Even if you have some ninja team of superhuman developers in your back pocket, they won't be able to parachute in at the last minute and do anything right away other than churn the project and introduce more problems.

Slipping the schedule is always tempting.  Reducing features is often what happens.  Sometimes we're smart about it and try to stage them together; reduce the features in the first release, with a schedule for releasing the remainder of the features in the future.

The worst thing that happens is when the decision is made to fight the triangle and keep the same schedule with the same features.  When that happens something else gives--Quality.

In software, when quality slips this usually means that the developers start to introduce hacks.

Magic numbers start to appear instead of declared variables.  Convoluted blocks of nested code get tucked into other functions instead of broken out into separate functions.  Blocks of code get commented out.  Blocks of code go undocumented.  Temporary variable names that make no sense get introduced.  Single purpose design takes over and expandable, scalable features fall by the way-side.  Unit tests and BAT tests go unwritten.

Your software product effectively gets downgraded to proof-of-concept.  When you need to build more later, you're instead spending time refactoring the junk you slapped together.  When users find errors it takes 5x as long to troubleshoot.  At the end of the day, you give up a lot more than you gained and always, always regret it.

Software Development

I've been doing professional software development of some kind or another since the mid-90's.  I wrote my first program on a Timex Sinclair when I was 10 years old, and taught myself Assembly to try to squeeze more into the 2K of RAM it came with.

pictured here with the 16K RAM upgrade!!  That changed everything!!

A lot has changed since then (thankfully).  Along the way I learned a lot of lessons--all of them the hard way.  Looking back at my first attempts at building a company, developing a brand, organizing a development methodology and cultivating people I realize I did things about as wrong as I could.

Here are some of those lessons.  Maybe you won't have to learn them the hard way, too...

Produce excellence, especially when you're not asked for it

My first commercial products were euphemistically called "Casual Games" or "Budget Extreme Sports Games" or more correctly "Shovelware".  Google "Extreme Paintbrawl" and read some of the reviews.  Enjoy the laughs and then come on back.

Extreme Paintbrawl and the games like it were precisely what our publisher hired us to do.  One important guy at a publisher told us "You could literally take a shit on the CD and I could sell it with the right licensing, just get them done as fast as possible."  So that's what we did.  We banged out junky games as fast as we could, because that's what we were hired to do.

This kept the lights on, and kept our customer satisfied, but it didn't lead anywhere.  Later on, when we tried to land bigger, higher-quality projects, nobody was interested.  We had a reputation for producing junk games at light speed.  Literally nobody would give us a shot at producing a quality game with more time and more budget.  In retrospect, they were probably right.  We had a shovelware culture and I'm not certain we could have turned the corner.

At the same time, a friend of mine with a very similar company and very similar starting point aligned his people around producing beautiful, compelling games.  He had the same customers, the same deadlines and the same budgets.  They were late all the time, the games were completely over-engineered relative to the spec, and they didn't make any money on those games, but they proved that his group could do really nice work.  They successfully segued into AAA games while I wound up throwing in the towel and leaving the industry.

Get a monkey on a football

On one of my early projects we had to develop a considerable amount of development infrastructure from scratch.  We were building a new rendering engine, new level design tools, new asset management tools and were working out of a basement.  Weeks went by with no visible progress to show the customer.  They started freaking out and threatened to cancel the contract.

I came up with a schedule of visible milestones to deliver to the customer.  For the first one I said "Look, I don't care if we render a monkey riding a flying football around the course, we have to show these guys something!!"  "A Monkey on a Football" became our catch-phrase for tangible customer deliverables that may not be completely required for the technical aspects of the development, but are completely required to make sure that your customers know you're moving forward.

It is a lesson I should have internalized from an earlier interaction with a guy named "Joris" in the Netherlands.  Joris had worked for us before and we hired him to write the AI for Santa in one of our early projects called "Nuclear Winter".  Joris kept telling us he was making progress and we kept believing him without demaning tangible proof.  When the time came for Joris to turn in his code, Joris disappeared.  Then he turned in corrupt zips, then disappeared again.  Eventually, Joris admitted that he hadn't done any work at all.  He had spent his entire advance on phonesex with some woman in Kansas that he was in love with and he needed more money from us and then he promised he would get right to work.  

So now, I always demand a monkey on a football from the folks who are working on my team, and I always give a monkey on a football to my stakeholders.

I have a few more, but my blogging time is up for this week... I'll post them another time.

options in the wild: part II

At the very beginning, I did a straightforward ROI type of analysis.  The decision seemed very clear from that perspective.  There was one line that took a little more work to get to, but was half as long and had twice as many windows operating.  It should have moved twice as fast.  Easy choice!

I hadn't considered the uncertainty in the model.

The people in line "d" were long a call option on all of the windows to the right.  If any of the windows from "e" through "h" opened up, they could easily exercise that option by walking over and moving to the new line.  I hadn't thought of that until it happened!

Once window "e" opened up, I sat there considering moving to line "e", thinking they might open up "f" or "g" or "h" and I didn't want to miss that opportunity, even though it meant moving to the back of the line.  I decided I was pot-committed to "b" when the other option in the mix made itself known...

The crew of any plane that happened by was long a call on window "a" and "b"!  Since I was in line "b", I was effectively the counterparty and short a call on those windows.  When the crew turned up and took over the windows, they exercised their call and my line came to a stop.

This story is a pretty good representation of the value of using a real options decision framework for a couple of reasons.  The most obvious reason is the importance of involving uncertainty in your decision.  If nothing had changed, my first choice was unquestionably the best.

The second reason is the importance of having a dynamic decision framework that can adapt to new information.  It's easy to make a straight-forward ROI type decision when you ignore the changing world.  One line was served by two windows and was half as long!  That's an idiot-proof decision!  A few minutes later, the decision was more complex.  I was at the end of a line that was roughly the same length as the others, but didn't have the advantage of more windows possibly opening up.  A few minutes after that, I was at a stand-still.  A robust, options-based decision framework that encapsulated the upcoming decisions would have helped.

From an executive decision making perspective, this sort of decision tool is almost never available.  What can be available, however, is some intelligence about what the inflection points are.  If I had any idea about the chances of another window opening up, or what the chances of a crew showing up, I could have produced some heuristics about comparative lengths of each line and made dynamic adjustments to my strategy when the real world changed in front of me.