Stay on Top of Enterprise Technology Trends
Get updates impacting your industry from our GigaOm Research Community
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.
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.
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.
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.
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.
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.
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.
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.