7 Comments

Summary:

Companies today are often so focused on growth that they commit one (or several) software development sins. Magne Land, the tech lead at RightScale, outlines these seven deadly sins and offers his advice on how to avoid committing these critical errors.

iStock-editorial-license_7-deadly-sins-Medium-1

Companies today are often so focused on growth that they commit one (or several) software development sins. As a developer at RightScale, a SaaS cloud management solution, I have borne witness to, and at times even been guilty of, the following temptations.

1. Lust

Getting other people to lust after your products can be very profitable. But software developers often lust for perfection, which can cause major problems. Mitch Kapor’s failed personal information manager, Chandler, is a good example of how this kind of desire can lead to a downfall. Kapor had founded Lotus, and Chandler was supposed to be the ultimate PIM. The project had plenty of upfront funding, wizard programmers and no real deadlines. These endless resources gave the team the illusion that perfection was achievable. But perfect never happens in software, because it’s fractal in nature. You can spend an infinite amount of time optimizing a very small part of the whole program. Chandler ultimately failed, because they were building a product that no user had asked for. By the time version 1.0 finally shipped, the rest of the world had already moved to the cloud and mobile devices.

2. Gluttony

Every company and developer is aware of software bloat, but many don’t understand how bad it really is. The problem is that hardware is improving so fast that developers believe they can afford to be gluttons of CPU cycles and memory. However, the sticking point is power consumption. Battery technology is only slowly improving, and cloud computing by itself does not conserve energy. So, writing smaller programs that consume fewer resources is about the greenest thing that you can do as a programmer. Also, if we assume that the average number of bugs per line of code is constant, then smaller is in fact better.

3. Greed

Arguably, we are in another valuation bubble right now, especially in the IPO market, and it’s easy to get greedy. The problem is that greed leads to short-term goals, which leads to technical debt and long-term slowness. The more features we hack in, the harder it becomes to maintain the whole product. Especially with large customers, it’s easy to bow down and implement a custom feature or one-off that may have a negative return on investment in the long run. If your one large customer decides to leave, what are you left with? Think strategically, and remember that your customers will appreciate a rock-solid product – they are rarely expecting it.

4. Sloth

Sloth is apathy, not laziness. An apathetic programmer is the arguably the most detrimental, because he has zero interest in quality. On the other hand, a lazy programmer can be a good programmer, because laziness can drive long-term efficiencies. For example, if I’m too lazy to type in my password everywhere, I might create a single sign-on feature. Or, if I’m too lazy to manually deploy software, I will instead write an automatic deployment tool. Laziness and scalability go hand in hand.

5. Wrath

Although many software engineers seem peaceful, underneath the surface often lurks a passive aggressive personality. Take a look at source code comments to see examples of this hidden hostility. Usually profanity in source code is proportional to technical debt. However, it is vital that your engineers are not milquetoasts. Beware of the programmer who does not ask questions or who will use any text editor willingly. Good programmers have strong opinions about almost everything, but they also appreciate lively debates.

6. Envy

Envy can be very dangerous in software development. Envy for other products often leads to feature creep. If someone mentions feature parity, you should ask, “But do we need it?” The ultimate killer feature is simplicity, but simple to use is hard to design. Also, it is easy to lose focus when you are constantly watching what other companies are doing. Imagine building towers out of Legos. Would you rather build one tower at a time or many towers in parallel? The parallel approach only works if the towers are identical. Otherwise, you spend too much time context switching. Agility is not the same as half-baked. And doing one thing well is still underappreciated.

7. Pride

On a small scale, excessive pride can lead to “just trust me” behavior that adds risk to the system.  On a large scale, it can lead to missing the next megatrend. When your employees start laughing at your customers, watch out! A lot of great companies have fallen due to excess pride. If your company rule is no hot patching of a production system, be assured that there will be a “trusted elder” who does exactly that on a regular basis. And eventually that behavior will lead to a system crash.  When your small startup is finally king of the hill, just remember: Only the paranoid survive.

Magne Land is currently the scrum master and tech lead at RightScale, a provider of multi-cloud management. Prior to RightScale, he worked for Citrix as a software engineer. Land enjoys running up the hills of Santa Barbara, doing 200-mile relays and drinking beer afterwards.

You’re subscribed! If you like, you can update your settings

  1. The problem isn’t gluttony, it’s stupidity. Software bloat is the result of real programmers building big fat platforms that candy coat software development so that people that have no business writing software can actually do so without needing to know about null terminating strings, how to manage the stack, release allocated memory, etc. and it just keeps piling up making it easier and simpler until it’s just massive bloatware to protect idiots that shouldn’t be programmers from themselves.

  2. emmanuelchenze Sunday, June 3, 2012

    Gluttony and sloth; I agree with those.

  3. Agreed. Nicely explained.

  4. Gluttony will be the killer of software development sooner than later! I developed C# with a guy that was convinced garbage collection would take care of everything. However, after much arguing and debate, I proved to him that his application that started out a mere 12MB, grew in size to over 900MB at which point most of the computers it ran on, crashed with “Out of memory” errors. I am a Delphi developer since 2000,(Pascal before that) that had to take the Microsoft shaft for a while, however I am back using RAD Studio XE in my full time job, and loving it! Designing small, native apps, that require no runtime compilers etc… and if you know how to handle memory properly, they stay small! Delphi and Firemonkey now give you the ability to design native apps for IOS, Android, Mac OS and Win 32 / 64. Development needs to take a step back to the days when we wrote small, well written, easy to debug code that ran well on 386 / 486 PC’s. Back then, hardware was such a rare commodity, that you took the time to write your code efficiently! Efficient code translates into more stable code, less bugs, less load on the PC and an end user that is happy with the speed of their application. Developers need to stop being clever, and trying to impress their fellow developers with fancy code, and keep it simple and functional! The PC will thank you, the end user will thank you, and mostly, your fellow developers will thank you!

    1. Totally agree!

      Years ago when the XT was “bleeding edge” I wanted to modify some hardware test routines on a 5.25 floppy and I needed to send five bytes of data to the hardware test device to reset it. The big problem was that there was only ONE cluster, a total of 512 bytes, left on the disk.

      I went to some engineers I knew and asked for an x86 assembler. When asked why I needed it, I told them “So I can make the code as small as possible.”

      Their reply was classic: “What do you care how small it is?”

      I found an assembler and wrote my little program: Five, count ‘em, a total of five “OUT” statements in a little .COM file that took up only 29 bytes when it was done.

      Even when I showed ‘em, they still did not understand the problem.

      Assembler was, and still is, my absolute favorite programming “language” – no matter what language I’m programming in. If assembly language programming – especially firmware programming – teaches anything it’s that a EEPROM or a flash ROM has only so many bytes of storage, and RAM is likewise a limited and precious resource.

      As far as I am concerned, any programer who wants to really be worth a damn should master the 6502 in 64k of RAM, before moving on to anything else in any other language.

      What say ye?

      Jim (JR)

  5. You missed the big one – dishonesty. Somewhere along the line, people started trusting engineers, simply because, well, they’re engineers. Not always a good idea.

    I’d like to see an article entitled “The 8 Biggest Lies Told By Developers” – for my money, they are:

    1. This Code Needs To Be Rewritten (Usually stated because the person lacks the relevant skills to venture into code they didn’t write, is to lazy to, or is simply after more billable hours)

    2. The Functionality You Need Doesn’t Exist Yet – We’ll Have To Build It (Doesn’t exist? Almost certainly a lie – in a world full of frameworks, libraries and crazy amounts of existing code, it’s astonishing how many developers still manage to get away with reinventing the wheel)

    3. I Know What I’m Doing (Yes, and that was me throwing the winning pass at last year’s SuperBowl as well)

    4. My Solution is Best (yes, if you don’t count the fifteen other solutions I didn’t bother to research or understand – or the cheap/fast solution that I didn’t tell you about because I couldn’t figure out how to make any money from it.)

    5. I Need More Resources (Because I chose the wrong framework/schema and rather than admit that, I’m going to apply a massive amount of gaffer tape and look for another job at the same time)

    6. I’m All About Simplicity and the User Experience (Uh-huh. So why can’t I understand your interface? Why do you hate one syllable words so much? Why are you refusing to put our phone number where it can be seen?)

    7. If We Work Too Fast, Quality Will Suffer (Somewhere in the world right now, an Olympic sprinter is mating with a software programmer and a child is about to grow up terribly confused – wanting to run as fast as possible while billing the maximum number of hours possible

    8. What I Do is So Complex You Couldn’t Possibly Understand It (Yeah? Try me.)

  6. IncediBill – you are right on the money. Sometimes it’s not enough to know how to work a starship. Sometimes, you need to know how a starship works.

Comments have been disabled for this post