Code Simplicity

Instant Gratification = Instant Failure

The broadest problem that I see in the software industry is that companies are unwilling to engage in strategies that only show results in the long term. Or, more specifically, that organizations are unaware that there is any such thing as a long-term strategy.

In the US, it’s probably a symptom of a general cultural problem–if an American can’t see an instant result from something, they think it doesn’t work. This leads to fast food, french fries, and fat people. The healthy way to eat (protein and vegetables) has a delayed effect on the body (you don’t get the energy for over an hour), and the bad way to eat (endless carbohydrates without nutritional value) has an instant result–immediate energy.

Software is always a long-term process. I wrote the first version of VCI in about three weeks, and that was insanely fast. Any actual application (VCI’s just a library) takes months or years of person-hours, even if you keep it small. So you’d think that organizations would be far-sighted about their development strategies, right?

Unfortunately, it just doesn’t happen. Competitor X comes out with “Shiny New Feature” and The Company says “we must have Shiny New Feature RIGHT NOW!” That’s not a long-term winning strategy, that’s just short-sighted panic. If you have users, they’re not all going to get up and go away in the next five minutes just because somebody else has one feature that you don’t. You should be looking at trends of how many users you’re gaining or losing, not just responding mindlessly to the immediate environment.

So what’s a good long-term strategy? Well, refactoring your code so that you will still be able to add features in the future, that’s a good one. Or spending some extra time putting some polish on your features and UI so that when the product is released, users are actually happy with it. Not adding features that you don’t want to maintain, if they’re not important enough–that’s another one.

Remember that Mozilla did poorly for years, only to finally start gaining dominance in a market that Netscape had lost, because they had a long-term plan. Granted, Mozilla made some decisions early on that caused some things to take longer than they should have, but they still won out in the long term, despite failing in the short term.

Of course, it can be hard to convince people that your long-term plan is right, sometimes, because it takes so long to show results! When I started refactoring Bugzilla about four years ago, there was pretty constant resistance, particularly when I would review patches and say, “You need to wait for the new architecture before this can go in,” or “This needs to be fixed to not be spaghetti code.” But once the refactoring really got rolling (after about two and a half years), it suddenly became way easier to add new features and nearly all the developers became big supporters of refactoring.

I read so much “advice” on “how to run your software business” that just focuses on instant gratification–what you can get done right now. “Add features!” “Get millions of dollars instantly from VCs!” Unfortunately, the way the universe seems to work is that you can destroy something in an instant, but it takes time to create something. So in reality, the closer you get to “instant gratification”, the closer you get to destruction of your product, your business, and your future.

If you want a good plan, pick one that admits that creation takes time. It doesn’t have to take forever, but it’s never instant.


13 Responses to Instant Gratification = Instant Failure

  1. jaiz says:


    Straight from your heart….

    . Long-term strategy is understood..But the problem is ” How much long…is long-term”..
    because this word “long-term strategy” has become a cliche…so.. people prefer “agile” systems rather than “seasoned systems” unless it is very critical for survival.

    • Max Kanat-Alexander says:

      Yeah. Now, I don’t object to what people call “agile methods” (although I really dislike buzzwords). They can be used inside of some long-term plan, if that’s what you decide is the best method. But yes, people often use various methods in a way that gives them only short-term results without taking a long-term look.

      In software, if even simple developments take months, long-term is pretty long term–at least years.


      • jaiz says:

        I agree buzzwords are pain in the ears (although I hate the cliche)
        But there should be someway of defining your idea..or will be just your idea….world will never know…

        Anyways… by agile .. what i mean is simple “do on. show…iteratively..quick”.. note i am using “improve”.. not “show”…also..”perfection is sometimes pronounced as a disease”.

        Good..Max… take care

  2. James Napolitano says:

    I had this exact problem at my last job. The boss just wanted us to implement his check list of features ASAP. When it came to taking any time plan out what kind of architecture or data structures to use, research what existing projects were available that we could build off of, or even to learn about the field we were in, he kept telling us to “just do all that stuff later, for the next version.” This was the coding equivalent of trying to decorate a new apartment before the building frames are up; it can’t be done, because features depend on and build off the core of your program. There even were expertly made, open source toolkits that we could have used to handle all the basic functionality of our program, but he didn’t want to take the time to research them and instead had us re-implement everything ourselves. As you can imagine, his project schedule kept getting bumped later and later, getting him madder and madder at us, and programmer after programmer mysteriously decided to leave. Of course, it didn’t help that his check-list included items like “extract 3D models from (2D) photographs”, which he expected me to do myself in maybe a few weeks, with no prior experience in image analysis or pattern recognition… I could go on for hours…

    I think one of the advantages open source projects have is that they are run by the programmers themselves, not management, so they naturally avoid all this inane, uninformed mismanagement.

    • Max Kanat-Alexander says:

      Hahahaha, wow! That man sounds like a fool. But I’ve heard stories exactly like that way too many times! It’s just sadly true.

      Yeah, that absolutely is one of the great things about open source projects. The people in charge always understand development, because they’re the developers. 🙂


    • jaiz says:

      James …

      May be true with your boss. but in reality this is the same reason why open source project are unable to fully leverage the market than the commercial vendors.

      It is great to see open source experts forking and perfecting their solutions , but the hardline is that they are trying to match an already existing commercial solution or doing some generic application…..

      “Water is useful only if it is accumulated , directed, purified and distributed across dedicated pipelines..”.

      However, i agree that todays IT managers cant be just “film directors” they need to be more a “servant leader”.

  3. It almost sounds like you are referencing generative thinking as described by Peter Senge in his book The Fifth Discipline. You might want to check it out.

  4. Boemer says:

    Sounds like the design of windows, make a lot of features put it together just before release and you got windows 3.1 to XP…

  5. Pingback: Code Simplicity » The Accuracy of Future Predictions

  6. Thanks for this, I think it’s time to tear down a few walls of my own. Although I think that it’s supposed to be “A temporary set back does NOT mean you have to quit.”

Leave a Reply

Your email address will not be published. Required fields are marked *