Coding: In Search of Imperfection - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

02:00 PM
John Edwards
John Edwards
Connect Directly

Coding: In Search of Imperfection

Learn why bad code is generally much better than no code all, except maybe in matters of life and death.

Pete Lumbis, a systems engineer with Cumulus Networks, doesn't like bad code. Yet he still believes that lousy code, despite its faults, is often better than having no code at all.

The reason is simple, Lumbis says. "In networking, or anywhere in computer science, we sometimes place a priority on perfection over getting things done," he explains. Yet poorly written code that still manages to accomplish its basic mission is always far superior to a coding project that drags on and on as its creator strives to develop an elegant masterpiece.

Lumbis acknowledges that perfection is critical in many projects, such when developing code for a heart monitor or a missile defense system. "But if I’m just trying to move a group of files around for some users, or I’m trying to create a bunch of descriptions on interfaces throughout my network, it doesn’t need to be perfect," he says.

Credit: Pixabay
Credit: Pixabay

There are many variations of bad yet generally functional code. Most often, crummy code is clumsy and hopelessly long. That's okay, Lumis says. "So what if it’s 200 lines, which somebody with better skills could have done in 10," he observes. "At the end of the day, if it’s saving you time and making your job better and easier, then the fact that the code is bad doesn’t really matter."

A Hard Habit to Break

Perfectionism is ingrained into many IT and network professionals from the moment they touch their first keyboard. "Most people who go into a technical discipline have at least a little bit of a perfectionist streak somewhere inside," Lumbis says. "It doesn’t mean that we always produce perfect work, but a lot of us take pride in ownership and so it’s hard to come to terms with the idea of doing something that’s bad."

Yet network professionals in particular are beginning to come around to the idea of settling for code that's sub par, but delivered quickly and fully functional. With software-defined networking (SDN) rapidly becoming a technology mainstay, network engineers are now finding themselves in the position of performing coding tasks they were never trained to handle. Yet Lumbis believes that network experts shouldn't feel bad when they create code that's rough and unpolished but still meets a project's basic requirements. "Software development is a completely unique and different discipline from network engineering," he says. "Yet even if we write some bad code, we can make our lives a lot better as network engineers."

Developing a New Skillset

Lumbis notes that fast and rough programming is simply a means toward reaching a goal. "We’re not going to create bad programming as a job with a salary range posted on Glassdoor," he says. "It’s about creating a new skillset, just as virtualization was a new skillset--it doesn’t mean that you need to be an expert."

Lumbis believes that network engineers are beginning to realize that programming -- even if it's not at an expert level -- is now a necessary job requirement. "You can see a growing community of network engineers trying to figure the situation out, being willing to take a stab at programming," he says. "Over the next three to five years, we’ll see network engineers not as software developers by any means, but as professionals with the ability to cobble together some bad programming code to accomplish a task."

Lumbis will explore the benefits of bad code in depth when he leads the session Imposter Syndrome: Bad Code Can Be Better Than No Code at Interop ITX on May 17 in Las Vegas.

John Edwards is a veteran business technology journalist. His work has appeared in The New York Times, The Washington Post, and numerous business and technology publications, including Computerworld, CFO Magazine, IBM Data Management Magazine, RFID Journal, and Electronic ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
2/26/2017 | 9:16:43 AM
Differences in bad
Bad is not the same as bad. Lengthy code that might not perform or scale well is fine for a feature that is used once in a while on a small set of records. While bad, it does not matter much that it is bad. The same badness in an often used feature that is applied to large numbers of records has a worse impact. That impact is noticed right away and the code is likely fixed before release.

Are we done here as the article suggests? Not at all! Unless we are absolutely certain, we eventually get a big problem when users start using the previously infrequently used feature more often or on large sets of records. Just because we did not intend that to be the case during design and test does not mean that it will not happen. Now we get customer complaints, more likely from heavy users with a large system and significant weight to throw around in the executive offices. As developers we now have to drop everything and fix this, push out an unscheduled update, and then catch up for lost time on our current assignments.

Leaving bad code in place is fine short term, but unless there is a plan to fix this soon after release, the chances are that the work has to be done at the most inconvenient time. Shipping knowlingly bad code is carry a debt that often is very difficult to be repaid.

Yet, there are still more differences. If this happens with some mobile app that is planned to be scrapped a year from now then don't worry about. Contrary, enterprise grade applications that are expected to be sold over a decade and that typically hang around for twice as long as anticipated.

So unless you work on throw-away apps, go fix your bad code asap and stop making up excuses that bad code is better than no code. In those cases bad code is as bad as no code, maybe even worse because there are no users who depend on that feature.
User Rank: Apprentice
2/14/2017 | 11:13:31 AM
how to fix bad code
So how come we don't have any AI applications that can rewrite bad code?  Maybe fixing bad code should be relegated to a computer and we can focus on writing quick and dirty code?
User Rank: Apprentice
2/14/2017 | 11:05:15 AM
about that imperfect code ...
maybe a better way to put it is "inelegant code."  if it is just unimaginative, it can still work, but i couldn't tell U how many times i have seen code that is "imperfect" because it was written by somebody who did not have a good grasp of the language being used, and who decided that he did not have time to check the documentation (or even google) to find a better approach to solving the problem at hand.

U can see some classic bad code at theDailyWTF dot com.  in cases like some of those, bad code that sort-of works in one place is symptomatic of bad code elsewhere that is failing in subtle, unanticipated ways.  such code often does more damage than good.

How GIS Data Can Help Fix Vaccine Distribution
Jessica Davis, Senior Editor, Enterprise Apps,  2/17/2021
Graph-Based AI Enters the Enterprise Mainstream
James Kobielus, Tech Analyst, Consultant and Author,  2/16/2021
11 Ways DevOps Is Evolving
Lisa Morgan, Freelance Writer,  2/18/2021
White Papers
Register for InformationWeek Newsletters
The State of Cloud Computing - Fall 2020
The State of Cloud Computing - Fall 2020
Download this report to compare how cloud usage and spending patterns have changed in 2020, and how respondents think they'll evolve over the next two years.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
Flash Poll