In the past, I have coded with some very bright and talented developers. Software development is like art, and I’ve worked along-side some true code artists. Their code is clean, readable, and expressive. Because of the care that they put into the design of their code, other developers can open the code base and, with a normal level of skill, modify or extend it with little or no prior knowledge. They are efficient and conscientious. I have a lot of respect for software developers like the guys with whom I’ve had the pleasure of working. I want to be just like them.

And then there’s the other type of developer. We’ll call him Einstein. Einstein is super smart. He thinks on a whole ‘nother level. In fact, he’s so smart that when he writes software, he writes it on a whole ‘nother level. On the UI level, the program runs and performs well. It does everything that it’s supposed to do. It might even do it REALLY well. Einstein has certainly outdone himself. He finished the project a few days early and the client is happy with the product.

Fast forward 6 months when the client needs to add a feature. Einstein is tied up with another project. The client has to hire another developer to modify the code base. We’ll call him Innocent Bystander. The client says to Innocent Bystander, “We’re really happy with Einstein’s work. You should have no trouble at all modifying this program.” So, Innocent Bystander cracks open the code and starts reading.

What he finds is a code base that only an author could love. It’s a tangled mess of spaghetti code and obscurely reused code blocks. Variables are named with acronyms that have long since been forgotten. There are no tests to show how code is expected to behave. Classes and methods cover pages and pages of scrolling. Nothing makes sense. It’s like trying to listen in on an encrypted conversation. The code base, for all intents and purposes, is encrypted.

So, Einstein was so “smart” that he wrote a code base that no one but he could understand. Innocent Bystander has accepted the task of adding a feature to that code base. Innocent Bystander has a couple choices… 1) Spend hours of the client’s time decrypting, modifying, and handling regression, or 2) Spend hours of the client’s time re-writing a section of the code, re-factoring the code that uses it, and handle regression. Either way, the client pays more than he should. Either way, there is regression. At least with the second option, the code base is left a little better than how Innocent Bystander found it.

Friends, countrymen, fellow developers. PLEASE please pLeAsE hear me out. If you are an Einstein and you’re still reading this… welcome to your first step to recovery. Admit you have a problem and start thinking about others while you code. Think about your client. Think about the next guy who has to come behind you. You don’t want either to hate you, right? Learn how to code in maintainable ways.

If you want to make sure your code is removed or re-written, just make it complicated and convoluted. No one will be able to follow your code and, boom… mission accomplished. You’ve effectively wasted the money of your client. The world would have been better off if you had applied your vast, immeasurable intelligence to something that lends itself to tangled webs of scattered thought process.. not software development.

If you want your code to stick around and make a difference, write it so that the next developer can read and understand it. Name your variables and methods to express their intent. Adhere to engineering principles like Single Responsibility, Open-Closed, and Dependency Inversion. Code in standard ways. Don’t try to be clever by stuffing loads of functionality into one reusable function. Spend time learning new ways to make your code expressive and readable.

No one cares how smart you are. It matters not that you’re on a whole ‘nother level. People only really care about your contribution over the long-haul. Clients may love you when you deliver the product early like a rock star, but the will cease to love you later when they have to pay again for the same code. No one will write blog articles about your awesome “swiss-army-knife-function-that-does-everything”. No, sir… in fact, they’ll write blog articles like this one.

  • http://www.facebook.com/chrkell Christopher Kellner

    Thanks for your post!
    I’m currently in the exact same position as “Innocent Bystander”. The last developer, who was working on my client’s little project, left me one (yes 1 ONE) Class (deriving from System.Windows.Form), which contains 10.000 lines of unstructured code!
    I’m totally enraged about this because I’m just a simple student, who got paid very .. limited and now I have to spend hours of hours refactoring the code. Plus, my client is not able to pay me for a compete re-write because he is running out of money.

    My Einstein completely destroyed my client’s vision as well as my time.

    Hope this will never happen again..

  • Anonymous

    Nice blog would like to add that
    NSE and BSE are one of the most superior stock exchanges of India. If you wish
    to earn good money from the share market then you need to understand the
    functionality of the stock market properly.

    Indian stock market offers lot of earning opportunities still many less traders
    earn from it. Now the question is who earns from the share trading? To be
    honest only those who rely on stock research as no one can earn big by
    speculating in the market.

    Regards

    SHARETIPSINFO TEAM

  • Einstein

    Your “Einstein” usually consists of a half-dozen or more developers of varying skills over a number of years.  By the time it gets to you it may be nothing like the original developer had intended.  In many cases we are usually just Innocent Bystanders. Rewriting the code for the sake of making it to your liking only compounds the problem for the next guy while wasting the client’s money on making you happy, not them. Take the time to learn what the code is doing instead of taking a quick glance and deciding nope, not the way I would do it, so time for a major rewrite. Though you may not be as smart as the dozen or so Einsteins that went before you in the code, recognize that you aren’t very smart before making an ass of yourself by a wasteful rewrite that is prone to new bugs, new testing, and more client money being spent on making you feel like you are smart, when in fact you are just an idiot.

    • Anonymous

      So, you’re saying that good code becomes spaghetti code because a team is involved? I’m sure that happens. I also think you’re right that “Einstein” can be made up of many people. That doesn’t pardon the team/group/architects/leaders/whoever for producing unmaintainable code that’s neck-deep in technical debt. It’s not fair to the client and it makes the coding experience for future developers less enjoyable. If I find unmaintainable code and I assess that it will take just as long to re-write it as it would to untangle and modify it, I will ALWAYS opt to re-write it. By doing so, I will have left the code base a little better than I found it for the next developer (and for the client, who will not have to pay quite as much for the next mod). 

      I’m actually glad I’m not so smart that I end up writing complicated, unreadable code. I don’t care about being smarter than the Einsteins out there… just better.

    • The Damn Steve

      I agree with Einstein.  It is not your place to do major rewrites of a functioning application.  Your inability to understand a piece of code does not actually imply anything about the code itself.  It says a lot more about you.  Stop trying to understand other developer’s code.  Instead, try to add more code without gaining any understanding at all.  It’s even better if you can mimic the existing code style or lack thereof without any knowledge of the reason for it.  The longer you can leave unmaintainable and untestable code in a production environment the better.  Have you ever actually worked for a client that cares if their application has a high probability of behaving as expected?  Of course not!  If they don’t care, why should you?

  • Anonymous

    One more thing… I work with a team every day. Granted, it’s a team of amazingly gifted programmers who are committed to writing maintainable code… but when we are finished with a project, it’s not a tangled ball of spaghetti. Just sayin’.

  • Anonymous

    One more thing… I work with a team every day. Granted, it’s a team of amazingly gifted programmers who are committed to writing maintainable code… but when we are finished with a project, it’s not a tangled ball of spaghetti. Just sayin’.

  • http://www.facebook.com/hjoab Holger André

    “Eisntein” is a misnomer for such “spaguetti coders”. If you have read Einstein, you realized that he always tried to make it easer for newcomers to understand what he thought. It was the theory what was hard to grasp not the way he wrote about it to explain it. These “spaghetti coders” justify their way of programming pretending to be genius coders writing the code (mysteriously like magic being product of their genius minds) that nobody can besides of them, but in fact what they do very well is to write things that anyone could understand (at least if they were well written) into a way that nobody can understand besides of them. Why? First. It is a business: if you wrote something that nobody else understands then they (the clients) have to come back with more money to make the changes. Second. The most of these “spaghetti coders” are empirical who have learnt their tricks in the front of the computer and never been in a low course on programming (or ethics by the way) at any computer science school at any faculty. That is, they program their way because they never learnt how to do it right (or cared ethically about it).

    • Anonymous

      Point taken. I didn’t mean to insult Einstein by pinning his name on these spaghetti coders.