No room for elegant code?

Question

Attempt at objectivity: This is based mostly on my small amount of experience.

I go through phases where I become dismayed and perceive that, ultimately, nobody really cares about writing good code. It becomes hard for me to care because I feel as if I'm the only one who does, and I see that as unnecessary concern. The problem seems like managers don't really seem to know if someone creates enormous messes of code that are bound together by duct tape, or if they keep it clean and attempt elegance. Should managers care? Most of me says yes, but they'd have to monitor the repository like a hawk.

I think the bigger issue is that I perceive a majority of professional developers being far too lax about development. There is no engineering going on, just throwing code at the wall until something works, and maybe cleaning out the dead code. If there's time. I've had more than one manager tell me not to worry about this, complete with dream-crushing smile, and a cop-out: "that's just the way the world works, son."

Am I off-base here? Are there places that value quality code? Because it seems like almost every software house would rather ship betas than tell their customers they will be late.

Answer 1

"they'd have to monitor the repository like a hawk."

No. They have to monitor recruitment like a hawk.

To answer your broader question - what you have to remember is that what actually matters is whether the program functions in such a way to bring the best possible benefit to the business taking into considering time, cost and risk. The (often mistaken) belief that code can "just work" is what IMO drives most people to act in the way you describe. Your challenge - should you choose to accept it - is to explain to them how this can bite them in the ass later on, and in the long run increase time, cost or risk, or reduce benefit.

Answer 2

Sounds like you need to find a new place to work.

There are certainly places where people, and management, care.

Answer 3

I wish I could say I had worked someone where that wasn't the norm, alas I cannot. Maybe you need to start your own company and lead the revolution? Maybe you just need to write this in your blog instead of ranting here?

Answer 4

This might be a reflection of where you work and the priorities of the company. It seems that when the priorities of the company but expediency over working (forget elegant) code you will get this attitude. Some people like this environment, it requires a lot of quick thinking and hacking things out. Yes it does degrade quality, and encourages lots of bad practices. However, management at your company appears to have accepted this tradeoff. They seem to be fine with always "working things out later" and "just getting it done".

You may also need to learn, in such environments, how to say no. How to try and decide for yourself, based on your principals what you should do. And how to convince others that something is the best choice. In many chaotic environments, you will have a very unclear chain of command. Things may get garbled and emergencies might conflict with each other for your time resources. Ultimately they are all coming to you, YOU have the power to deal with these emergencies and you need to be somewhat assertive. You need to be savvy, diplomatic, convincing, and be good at managing your time. You also need to prove yourself, skillwise, so others feel they can trust you.

When others recognize your skill and your abilities and once you are assertive and diplomatic with your power, they will begin to look up to you. They will respect your opinion when you assert something needs to be refactored or redesigned.

Ultimately then you can "push back" and create a little space for you to create some higher quality (maybe more elegant) code.

Answer 5

I am completely getting your point, I have experienced the same. It depends on the organization and its processes. Most of the time managers are just care about the deadline and profit of the project as their prime priority. But a way to solve this issue is to have a greated quality control team in your organization. May be your Technical Team Lead or a technical manager takes the responsibility of the code quality. He will do that job by reviewing and making sure everybody meet standards of the organization and quality of source code.

Answer 6

There's room for a bit of everything. Your job is not to create elegant code. Your job is to create value for your company by writing code. The importance of quality depends upon the requirements of the job and the type of development you are doing. If you are working on $30K, one month engagement style of websites then unfortunately, quality is not all that important. In fact, if it can be undesirable if it causes you to take more time (re: profit) to do a great job than it would to do the quick and dirty hack.

However, if you are working on the Base Class Library for Microsoft (for instance), then quality would be of overwhelming importance.

So, like most of these types of questions, the answer is, 'it depends . . .'

Answer 7

For the subject of this response, I'll define "quality code" as code that's well designed, has a clear structure and is easy to understand in addition to the fact that it does what it should do.

"sub-par code" would be code that does what it should do, but little else. It's badly designed (if at all), contains many special cases and just barely does what it should (possibly but not necessarily with quite a few bugs).

The value of quality code is a lot harder to grasp and to convey the value of code that works.

When a developer produces quality code for some feature then he will generally take longer for the initial implementation as if he where content with sub-par code. To a manager this seems to imply that "quality code" means longer development time with no apparent advantage (since both versions will work).

Now when a problem or a change request pops up later on, then management will usually have the impression that the time and effort needed to do that work depends only on the skill of the developer doing the fixing. The fact that the initial investment can greatly reduce the cost of later changes is rarely seen (especially since there is no good metric for "quality" of code).

This lack of visibility and useful metrics together with a constant pressure to release leads to the very low priority that code quality has in many shops.

Of course the fact that developers themselves often claim "but I don't have time to write good code" doesn't really help.

Answer 8

The only thing you can really do is maintain a level of "elegance" for yourself. I have a strict coding standard I adhere to religiously. If there is a coding standard already in place I will obviously use that, but usually I suggest my one and buy in is usually pretty good.

The problem with being a working coder is bottom line is the most important thing. A lot of coders are lazy and just code without thinking to get the job done/manager off back/bills paid etc.

There is absolutely no reason to not be able to do both, especially when firefighting mistakes or bad process takes more time than doing it right.

Having been around in the industry for a while, I do see that we are getting better as a whole. Maybe you just need to find a work place that has good standards and process in place?

Answer 9

Many businesses look at the bottom line, and wonder if code that works "well enough," and takes one-third the time to produce, might be better at the end of the day, than a work of art that no one will ever see.

Also code is ephemeral. One doesn't know if one project will succeed and have longevity, while another project gets killed. So is it worth it to invest so much time and care, when there's an even chance that the code will get scrapped anyway? If the project succeeds, these businesses may assume there'll be a chance to refactor the code.

I wish I could say that high-quality code is more likely to succeed, but that doesn't seem to be a factor. In fact, if time-to-market is crucial, it's often the quick-and-dirty code that becomes more successful.

Answer 10

I guess it depends on the life of the product you're building.

Most of the times, when you're building a piece of software for a customer with tight deadlines, theres no much choice. Is either you make it right in 2 days or you copy/paste it in 2 hrs ( never do that btw )

I have been in the same situation several times. The bad thing is that I cannot just pretend there's bad code under those files, and I spent a lot of time refactoring it. Sometimes I just change the part that concerns me.

But if the product you're building is something that you'll maintain for years ( let's say the source code of SO ) it is mandatory the management team put a lot of effort in keeping the code clean. It is an investment in the long run.

That's when peer reviews and weekly refactorings are most useful.

Answer 11

You need to move into an area of development where ideas matter, and smart people are valued, and code solves problems rather than just shuttling data around between browsers and databases.

I can't fault your manager too much, because he's probably right. In many development shops, elegant code really isn't important. Because they're not developing elegant software. And they're not solving elegant problems. And they don't have elegant clients.

In those kinds of environments, keeping costs down and minimizing development time is more important than just about everything else.

He probably should have said "that's the way OUR world works", but thanks to myopia, he doesn't know the difference.

There are lots of software companies that care very much about the fundamental principles of computer science. They solve difficult computational problems for demanding clients and code quality is a top priority.

Figure out where those places are, and go there.

Answer 12

I think one elegance inhibitor is our increasing dependence on framework-generated code. You need to IMO pretty nearly be aware of every line of code, it's purpose and structure, for it to be elegant. You want to be able to say "That's there because I put it there, and it's the right place for it to be." Most of the time generated code puts stuff there to prevent unintended consequences from exigencies that your elegant design already prevents.

The other force at play is the fact that software is increasingly developed by teams of people; and elegance by itself only works when everyone contributing accurately understands "how this works". Consequently, consistency trumps creativity.

I'd be interested if anyone else also feels (inituitively, not cognitively) that static languages like java and c# inhibit creativity compared with dynamic languages like javascript, perl, and Ruby. I seem to spend more time housekeeping than conceiving; and once a set of classes is in place, refactoring seems like more work. (And obviously you can do a lot more irrecoverable damage a lot more quickly, too.)

Answer 13

Unfotunately, what you are describing is pretty common. I don't think it is just a matter of developers becoming lax.

That kind of attitude comes from management style, organisational culture, and economic realities, and you can't really blame anyone for that, most managers that I have known do actually care about keeping their staff employed, being able to pay bonuses,..., elegant code comes second to those more pressing factors.

Customers are interested in something that works, is on time, and on budget, and most of them really don't care about anything else. Most often, they will go with the cheapest and fastest bid for the job. That is what forces everyone into the situation in the first place.

This is not just our industry either, how many cabinet makers are there that cut dovetail joints anymore? Much as they might love to as an expression of their craft, they are competing with products that are glued and stapled together. Some do, for sure, but they have an elite clientele.

There are still some places that value quality, but they have to have found a way of making it viable in a tough market.

Answer 14

Actually most people are extremely poor judges of if their code is good or not. In fact, it's possibly true that people are unable to ever judge their own code.

Managers are even worse--they wouldn't know how to start.

What you might want to look at is certain metrics. If you keep track of the right metrics, maybe you can convince a manager.

If your code is good, you'll find it takes about as long to write as bad code maybe a few percent longer. Once it's done, mainly you will notice that you almost never have to touch it again (in comparison to bad code in the project)

Check how much time others spend learning your code--your code should need little explanation even when being reviewed by a poor programmer.

Record how much time is spent reworking other peoples code and not yours.

Watch how changing requirements barely effect your code.

You might point out when you get stuck in QA for a man-month (that's 4 people for a week, happens all the time) on something that took someone 2 weeks to write, that your good code hasn't had such treatment, and you're betting it never will.

These are the things a good manager should be able to comprehend easily, heck even a bad one should be able to grasp the concepts.

If you don't notice much of a difference in these metrics, you may want to reconsider your definition of good code.

Answer 15

The big problem is that most people still see the quality of the code as being an entirely subjective issue. Once you've seen enough programmers in web-based discussions talk about how they've never seen beautiful or elegant code, you start to get a true sense of the current (depressing) state of the industry.

The truth is that the underlying mathematical nature of software code makes it more than amenable to being normalized. You can apply objective rules to the code to make sure that very specific properties are achieved, in the same way that you can apply similar rules to a relational database structure. For more details see:

http://theprogrammersparadox.blogspot.com/2008/11/code-normal-form.html

Fully normalized code, to some high degree, will absolutely make a huge difference for a project. For a relatively small amount of effort you can turn what was an ugly unwieldy mess of code into a foundation on which to build more sophisticated functionality. The trick to software is not to write millions of lines, it's to leverage your work as much as possible, so extending code is way better than cut and pasting it over and over again.

Many software development projects just turn into hideously ugly pits of crappy code layered around crappy code, and as an industry we, the programmers let them do it. The one big thing that most programmers dread is spending their afternoons fixing other programmer's messes. Of course, as long as that doesn't change, most of the larger code bases will continue to be filled with hastily written, poorly tested, bug infested, pulp, much of which barely gets run, if ever at all.

You should be dismayed, there is no real reason why it has to be this way ... (and the stupid part is that it just makes it harder to get things done, and more likely to fail)

Paul.

Answer 16

A great way to bring these to light to a manager is talk the manager into doing code reviews. Code reviews are a great learning tool as well. Have 1 hour set aside each month to have a DEV show off a piece of code he worked on that the team chooses. Then the team critigues the code. If the same person always has messy uncommented and totally nasty code it will be shown in a code review.

Horribly written code is bad for everyone. If that person leaves and you have to fix something that is broken it could take you hours or even weeks to correct if you cant make out what the code is supposed to do.

Answer 17

I encourage you to try to go freelance for a year or two and see what type of code you produce. This is an economic question, and I honestly believe that economics are such that while sometimes you have to take bad shortcuts to make enough profit to survive and achieve your goals, there are still other times when the savings created by using best practice coding standards will pay off -- in profit.

Maybe if you freelance for a year or two you can wind up starting you own business and cater to clients in situations where the payoff from high quality code is evident.

And then we can all come work for you!

Answer 18

As you've correctly identified, getting Management buy-in is crucial.

Code reviews, good practices, start off as a net cost to start with, and this is what is holding your "dream crushing" manager back.

As with a lot of things, this then becomes a marketing exercise. You'll have to persuade him in his own language why elegant code/good design matters. Phrases like:

• not just firefighting but
• taking the product to the next level, giving us
• competitive edge and
• faster time to market for new functionality

I wouldn't spend too much time on words which evoke the haute-couture, but can be legitimately used - "elegance", "beauty" etc, but focus on "good", "quality", "design" etc

If you can't get buy in then you've got a problem, which is ultimately only solved by:

• having the power to run your own team with your own quality guidelines
• changing the culture from within, which is slow going to start with, and if you're doing it without management buy-in you'll still be tasked with your usual workload.
• find another job that rates quality/elegance/simplicity more highly.

None of these last options seem palatable.