Habit 6: Reuse Is For Wimps

Today’s Habit is brought to you by the letter “R” and the number 1.

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Reuse Is For Wimps

recycle
Not Just For Plastic, Glass and Cans

Feeling that urge to rewrite qsort?  Convinced you can write a better Hibernate than Hibernate?  Positive that there is no XML parser out there that will suffice for your project?  Um.  Put down that Erlang compiler a sec and listen.

I completely understand why these urges come up.  We love to solve problems.  And sometimes, writing a billing application isn’t nearly as fun as say, creating a custom persistence layer that converts XML to binary ZIP and inserts it into a BLOB in the database.  But you won’t get a promotion because you reinvented the GOTO in your custom Haskell extension.  You might get a promotion because you shipped a working product on time, under budget that delighted your customers.

The goal of every software project is to launch.  Anything that gets you to launch quicker is good.  Previously developed libraries, even beta-grade ones, can be a win for you and your team.  That’s not to say you should create a Frankenapp by bolting every Open Source project together within reach.  But making judicious use of the right technologies can substantially reduce your time to market.

The one (and I do mean ONE exception) is creating something that is part of your core competency.  If you’re Intuit, then accounting software is your core competency and you’d better write some cool 401(k) prediction algorithms to help people use Quicken more effectively.  But what about a web framework?  Intuit isn’t in the business of creating frameworks.  Should they write a brand new one?  Probably not.  Understand what you’re in the business of doing, and write THAT.  Find help for everything else, as much as you can.

Habit 5: Fix It Later

We examine the power of procrastination in today’s post, and why you should never underestimate the impact on your future.  If you missed the early habits, they’re linked here:

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Fix It Later

How many times have you said to yourself,

“Bah…I don’t have time to do that now.  I’ll fix it later…

bug_costs
Anything is More Believable When It's Graphed

Yeah, I thought so.  I do it too.  But a disciplined developer will stop right then and there, think about the future cost of that mistake and then correct it on the spot.  It’s the difference between knowledge and wisdom.

Comp Sci majors are taught from basic coursework (usually in their ONE software engineering capstone course, sadly) that the cost of fixing errors goes up non-linearly as you move forward in a project to later phases–fixing a bug in the requirements during say, design, is cheaper than fixing the same bug in production.  A practiced engineer will apply that knowledge to fix problems BEFORE they get into the next phase by proactively understanding the consequences now and altering the course of history.

The temptation (and sometimes the stick that is whacking you on the backside) is to say you don’t have time because of The Schedule.  The Schedule will always be there.  You’ll almost never work on an open-ended project with infinite time to “get things right.”  You will have to ship, eventually.  That comes with compromises.  We defer changes out of fear.  Fear of impacting others.  Fear of being wrong.  Fear of having more work to do.  What’s that you say?  “I’m the exception!  I can’t just go changing that class because it’s already in production and I don’t know what it will break.”   Thank you, that’s the point.  THAT bug made it to production because someone said, “I’ll fix it later.”  So fix it now.

Habit 4: Never Share Information

Lessons from Lord of the Rings, why you really did learn all you needed to know in Kindergarten and the value of opening your kimono.

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Keep Important Information Secret And Safe

All that knowledge you’ve worked hard to acquire over the years…it should be jealously guarded, like a treasure in a cave.  Never shared.  My PREH-SHUSSSSS!

Filthy Colleagues-es!  They wants the Precious!
Filthy Colleagues-es! They wants the Precious!

Who are you, Gollum?  You may remember it didn’t work out so well for him.

The best developers actively share and disseminate their practices, tricks, tips and past pitfalls with everyone and anyone who will listen.  They teach and mentor new developers, write good documentation (OK, they at least write it…), send emails to the team letting them know about new tools and techniques for making things better.  They do Brown Bag seminars talking about the latest project and how it was useful to them, the company, or their peers.  They see problems in training and make up for it by creating Wikis for new team members.

There is no point in holding on to useful information that could make others better developers.  That is, unless you’re trying to stay in the same job forever.  Ask yourself, who do you want to work with on your next job?  The person who helped you write that complex algorithm on their lunch break, or the guy who hissed at you when you walked into his cube:  “Mine!  Stay away, filthy Hobbitses”.

Yeah, I thought so.

Habit 3: Complexity Demonstrates Intelligence

Smart people naturally create…chaos?  Today’s habit is about the value of parsimony in your work.  Previous habits linked here:

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Demonstrate Your Intelligence With Complexity

escher-relativity1
Ow, my head hurts...

Project complexity creeps in from two paths.  First, there’s accidental complexity.  As developers we love solving ALL kinds of problems–that’s usually why we choose this field.  Often times we start solving the problem before thinking about it first.  The result is stream-of-consciousness code, where even YOU won’t understand it in six months.  With comments.  As Mr. T would say, “I pity the fool”.

How about the developer that actively accidentally obfuscates their code by using counter intuitive algorithms, poorly named variables, or seven levels of indirection.  This intentional complexity is even more insane.  I’m not sure if this comes from some Napoleon complex in software, lack of training/experience or just a naive repertoire of coding tools.  Either way, it sucks for everyone else down the line from your code.

Simple code is easy to read, easy to maintain, and a joy to work on.  Sometimes, simple code will naturally evolve from complex code during the course of code reviews or pair programming efforts.  The best programmers I’ve ever worked with have one thing in common:  making complex things simpler.  And despite what I read about this Python library experience, simplicity pays for itself down the road.  Being afraid that a simple solution makes you appear less smart is crazy.  Want to prove how smart you are?  Try teaching some training class to your peers instead.

There are some easy ways to help fight both kinds of complexity:

  • Google the problem before you attempt solve it.  See if a solution already exists.  Understand that solution first.
  • If you only understand one solution to a problem, ask someone else for a different perspective, especially if you struggled with that answer.
  • Refactor if you don’t like it the first time.
  • Actively seek to reuse existing libraries.

Endeavor to make things easier for yourself and others.  The sanity you save may be your own.

Habit 2: Confuse Motion With Action

We explore the difference between work and heat in today’s habit.

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Confuse Motion With Action

Lots of people misunderstand the difference between motion and action.  Or in physics terms, the difference between work (energy put into a system that increases the potential of an object) vs. heat (energy expended but with no future value, like friction).   Steve Blank recently made a memorable post on it:

sisyphus
Sisyphus Enjoyed His Daily Routine...right?

Steve: Jim, how are we doing with getting Ansys ported?
Jim: Great, I have a bunch of calls into them.
Steve: How are we doing on the Nastran port?
Jim: Wonderful, they said they’ll get back to me next month.
Steve: How about Dyna 3D?
Jim: It’s going great, we’re on their list

Putting in the effort to look busy is not the same as making real progress towards a goal. I’ve sat in countless meetings listening to this sort of status reporting (at all levels, not just for developers either) and I’m sure you have too.  Oh, wait…you’ve given a status report like that?  Yeah, me too.  Next time you’re tempted to do that, look at the problem differently:

  • What goal do I need to accomplish?
  • What is in my way of doing that?
  • How can I get rid of those obstacles?
<li><a href=”http://www.lessonsoffailure.com/software/seven-habits-highly-dysfunctional-enterprise-developers”>Blame Everyone But Yourself</a></li>
<li><a href=”http://www.lessonsoffailure.com/software/habit-2-confuse-motion-with-action”>Confuse Motion With Action</a></li>
<li><a href=”http://www.lessonsoffailure.com/software/habit-3-complexity-demonstrates-intelligence”>Use Complexity To Demonstrate Intelligence</a></li>
<li><a href=”http://www.lessonsoffailure.com/software/habit-4-never-share-information”>Keep Important Information Secret And Safe</a></li>
<li><a href=”http://www.lessonsoffailure.com/software/habit-5-fix-it-later”>Fix It Later</a></li>
<li><a href=”http://www.lessonsoffailure.com/software/habit-6-reuse-wimps”>Reuse Is Overrated</a></li>
<li><a href=”http://www.lessonsoffailure.com/software/habit-7-principles-important-results”>Principles Are More Important Than Results</a></li>

Seven Habits of Highly Dysfunctional Enterprise Developers

With apologies to Steven Covey and Jack Ganssle, who have their own lists on the topic, I bring you the

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Blame Everyone But Yourself

finger-pointing2
Who me?

There’s always plenty of people on enterprise software projects.  Everyone shares the responsibility…and the blame.  Developers often use this situation to deflect the blame.  I call this the Code Kingdom Problem.  That’s not MY code, it’s YOUR codeI didn’t write that module, S/HE did…And so on.  Maybe this statement rings a bell:

“Hey Bob, since you wrote that parsing module and the bug that came up seems to be a parsing error, why don’t you fix it?

Tempting though this may be, consider the collateral damage caused by this causal remark:

  • Bob may resent you pointing out his failures
  • Bob may not want to collaborate with you on future work
  • Bob may not recommend you on future jobs
  • Bob may spit in your coffee when you’re not looking

Rather than risk Bob’s heinous salivary wrath, why not proactively fix the problem (Cooperative Code Sharing), or help Bob find it and suggest a fix if Bob is struggling with it? (Pair programming).  Bottom line:  Their is no MY code vs. YOUR code.  It’s OUR code. If you’re on the project, you share it all–failure, success, or mediocrity.  You can’t have pride of ownership without ownership.

Adapt or Die Thinking You’re Right

From the late 1800s until the 1950s, railroads dominated the transportation landscape.  Want to go from LA to Chicago?  Chances were you did that by train.  It was the preferred choice of the traveler–cost effective, comfortable, and enjoyable.  In short, the railroads enjoyed a near monopoly on passenger movement for nearly 100 years.

When the automobile began to dominate the landscape, railroads simply ignored the threat.  “We are vastly superior, have a lock on many markets, and offer an experience you can’t touch!”  Unfortunately, the American consumer disagreed with them and railroads entered a period of decline.  Cars became the preferred mode of transportation, changing the way cities were built and how people spent their leisure time.  By 1966, railroads only carried 2% of all intercity passenger traffic.  And by 1970, only one major railroad carried passengers at all.  The railroads shrank, cut routes, and closed down wondering what happened.  This is now a classic example in business texts, MBA courses and lectures:  railroads failed to understand they were in the transportation business, not the passenger business.  They didn’t realize their core strengths causing certain death when their market shifted.

Back in the early 90s, my first job out of college was technical support at a GUI toolkit company.  This company’s claim to fame was a platform portable library(written in C, later adding a C++ framework) where you could build a user interface on say Windows and then move it to Motif, Mac, OS/2 or a litany of other unfamiliar and obscure platforms, recompile and BOOM, your app ran there too.  At the time, it was a novel concept and one folks were paying a mighty fine premium to obtain.  Licenses ran about $2000 a piece, plus annual maintenance for support.  Writing these kind of applications required a level of GUI expertise that wasn’t commonly available to many developers of the era which gave rise to a Consulting and Training Group that charged hefty rates for their highly sought-after services.  Life was good:  the company sold several million dollars of support, product and services each year.  ISVs writing C and C++ applications gobbled up the software as voraciously as their CFOs would approve the purchase orders, creating a very large and lucrative market during that time.  They were kings of the hill.

Fast forward about 3 years.  Java and HTML appear on the scene.  Younger developers in the company are checking these new technologies out and sending emails to the executives saying how cool Java is and how HTML is taking over the world.  The executives didn’t care.  “HTML?  Bah, that’s for children.  Java?  A toy language at best…all it can do is make Duke dance in an applet window.  Ignore them.  We have the Enterprise to worry about.”  They missed the point.  They were in the business of providing a platform-portable GUI development solution.  They forgot that technology doesn’t factor into their mission statement.  They were focused on getting new customers in their existing market.  They insisted everyone would use C++ forever because it sucked less than HTML and Java, instead of seeing how the market had changed.  Just like the railroads.

A few years later, the company shrank from the 100+ employees in 1994 to less than 5 by the Millennium.  Developers left in droves because Java was the hot new language and C++ developers were in demand.  Professional services was sold to another company because management wanted to “focus on product sales, not services”.  The product sales dried up slowly and only a few stubborn customers who couldn’t get off their C/C++ platforms paid the outrageous maintenance fees charged by the remaining shell company.  Java became the defacto language for the enterprise.  HTML is the lowest common denominator of every web framework today.

Seth Godin nailed this in a short post:  When you have a hammer, everything looks like a nail.  But making sure you have the right tool for the right market is about how quickly and easily you can switch hammers.  Not hitting the same nail again and again.

The lesson here is clear:  Understand your strengths because your market isn’t static.  When the market changes, be prepared to adapt to it with those strengths. Otherwise, you’ll die thinking your strategy was right.