Nobody Cares What Your Code Looks Like

blog
41

Jeff, I can’t help but feel that you used the wrong example for your topic. The example seemed to question the choice of language, in hindsight, rather than the attractiveness of the underlying code base. I will grant that the end user may not care about either one, but the example and the topic are not synonymous.

This blog has already been pretty well flogged but I’ll add my 2.

Many of the respondents focused on pretty code which I also think is off the mark; yes pretty code is easier to maintain than not pretty code but the “prettiness” is not the real issue IMO. It is the underlying design. An app with pretty code and a poor design is still hard to maintain. A well designed app, even with not pretty code, is easier to maintain.

Some current IDEs, like VS2005 2008, take care of the prettiness of the code for us, almost more than I’d like; what they won’t do is address the design of the app. I started coding with db3 and FoxBase where you could make for some butt ugly code and designs; I found along the way that if I made it pretty I also started learning how to design it better. At this point I’ll write something, getting it working then refactor it, especially if I need the same chunk of code again and it get’s encapsulated. The use of meaningful names for objects and variables goes along way to easing on maintenance too, although this is not a prettiness item it is even more important, IMHO.

On a larger scale your topic “Nobody Cares What Your Code Looks Like” is also a comment about our society at large, and is true. If it weren’t you would not see all the crap from Wal-Mart/China. Things that look good in the shrink-wrap but after a few uses start falling apart; that’s the result of shopping for the lowest price and it affects all of us everyday at the cost of many quality oriented businesses that customers were not willing to support because they did not know/understand what went into producing a quality product so shop for price not quality.

Reminds me of the old saying:
Cheap
Fast
Good
Pick two – the one you don’t pick is the one you don’t get.

Keep up the good work.

Merry Christmas, Happy Hanukah, Merry Kwanza

42

Users don’t directly care about the state of the code, that’s right.

They care about what affects them which includes bugs, the pace of development and features they need.

And all of those are affected by the state of the code.

[)amien

43

Max was saying that he thinks they should consider changing to a different language because of the amount of time involved when coding in Perl is greater than the amount of time his competitors are spending doing similar things with different languages.

That’s not really the same as Max saying that he cares about how his code “looks”.

bad code does take longer to maintain - so I think I missed your point in this post.

:slight_smile:

44

“But perhaps we should also focus a bit more on things the customer will see and care about, and less on the things they never will.”

This is kind of a chicken and egg situation if you ask me but I would argue that how your code looks will have an immense effect on the customers overall experience.

The easier your code is to understand, modify and debug the more time you can spend on the user experience and the better the end result will be.

45

Not to beat an already dead horse, but I think you are off base here.

Code quality matters. Code quality is completely invisible to the users and marketers and sales droids and CEO. However, its effects are nebulous yet dramatic: projects taking an extraordinarily long time to complete, long break/fix cycles filled with unexpected regressions, innovation stagnation. These are highly-nebulous effects. How are you to know if Widget X is taking a really hard time because your codebase is stuck in 1989 or because making widgets like Widget X is just a complicated problem?

Code meeting customer goals, working, performing well enough, getting sold: all these things are first-level effects of your product. When they are no happening, you know immediately. Fixing these is an easy task to diagnose (relatively speaking) and engineer.

It is, therefore, a great engineer who concentrates more on the “cleanness” of his code, its maintainability, its documentability and documentation, over the specifics of the feature set or performance. The entire rest of the company can bring those deficiencies to his attention, if they exist. Only HE can see that his code is structured like ropey pasta and takes a 100-page dissertation to explain the whats and whys of a 2-screen method.

46

Indirectly, I care greatly about the code in a piece of software: specifically I care about how fast and how secure it is. The majority of managers I have spoken to care greatly about productivity and security, both of which are affected by code design. Here I present my case. (I would be interested in hearing counter arguments :slight_smile: )

I can personally describe ideas in English and Welsh (very inelegantly), but I have many colleagues who can describe the same ideas in English, Chinese, Japanese, French, German, Spanish, Dutch, Welsh (beautifully), Hindi, and I’m sure I’ve missed some.

Some of these languages have optimisations over others. For example:

Welsh os gwelwch yn dda / Welsh (5 syllables)
means
English please / English (1 syllable) ( more strictly, “if it’s your good will”)

thus leading to the proposition: English is more efficient than Welsh.

However:

Welsh Ga’i beint o ddwr?/ Welsh (4 syllables)
means
English May I have a pint of Water?/ English (8 syllables)

so we can now improve our previous proposition to: English is more efficient than Welsh in certain situations.

I am English, and don’t remember learning to listen, speak, read or write. I can naturally hear grammatical errors, even less-than-optimum grammatical structures, and I’m sure that this is also true for you in your native language. I learnt to speak some Welsh at University, and do not consider myself fluent. I am incapable of hearing grammatical errors, let alone sub-optimal constructions, in Welsh - although I can make myself understood (at least some of the time).

Whilst recently I have specialised in Perl, I have been lucky enough to teach Perl, Python, PHP, Javascript, Java, C, C++, SQL, sed+awk+shell+commands and a couple of others in a UK University. OK, I’m being loose with my definition of language, but the point remains: I can write any of those of the top of my head, but I will be more “fluent” in one than an other.

It is important to strive to know the language as best as possible, and to use it’s features in the most optimum fashion - which may not be the same across all languages.

Might I suggest that perhaps it’s not the language directly that is the problem. Perl is a language designed to be exceptionally good with strings - mostly, a web server (even the new technologies supported by a web server) use text based strings. It is reasonable as a coder to expect fast and intuitive string manipulation techniques built into the language for free.
I’m sure no-one here is suggesting to me that there is stopping you using AJAX with Perl or mod_perl, it’s all string manipulation in the end.
However, if most people are competent but not fluent in Perl, the project is going to run into problems.

Watching people learn to write algorithms in University, the observation I have made is that a problem with an algorithm is always going to be catastrophic compared missing a brand new feature that you have been given in a different language. Remember: on a small project one language will outstrip another, like Welsh will always outstrip English when politely ordering water in a bar. On a larger project, there will be bits that perform better, and others that will perform worse, when you compare to other languages.

One of the most important resources in any coding community is people. If you have many people willing to donate their time, and have a fluency in a particular language, do not ignore that. If you do, I think you’ll find sub optimum grammatical structures, which will only serve to hurt you in the long run.

I am no zealot for GNU Linux, BSD, Sun, Apple, Microsoft products, Perl, C, C++, Ruby, etc. However I strongly advocate the correct tool for the job-in-hand.

Might I suggest that you take stock of your coders, and find the language that the majority of people are fluent in? If that’s Perl, stick with it. If not, use the language which presents itself.

47

@Brian:
"From my experience, project based work is the nemesis. Here you are asked to add x amount of functionality in the minimum amount of time, often working on code developed else where. You just don’t have the time or the luxury of cleaning up the old code. Instead you find yourself layering on new code over old code while keeping you fingers crossed that your change isn’t the change that breaks the application.

The programmer cares about the code, but the project manager doesn’t. They’re the ones who are measured on delivery on time, on budget and on spec. Their perspective is purely myopic. They can see to the end of the project and no further."

You say “You just don’t have the time” … who defines what time you have? If it is a poject manager making up engineering LOEs from whole cloth then your organization is severely F*'d. Get out while you can, or change it from within: it will implode in just a few development cycles if this doesn’t change!

It is true that there is a tendency for projects to be under-estimated and over-scoped, but I’d not blame it on project-based work, but rather on a poor management (and this is the part of the engineering manager, not the engineer, unless no such beast exists in the organization) of LOEs from engineers. Engineering managers should always be asking their engineers: does that LOE map to the “right” solution or the “easy” solution? What are the long-term impacts of this solution on the code? Are there smaller-scale bits we need to add to this project as dependencies? This will get sent up to the project after having been multiplied by an escalation factor (ideally specific to the engineer and his past estimates as well as the relative state of the code being modified and the risk attendant in the project).

The time you have is what you define it to be. If that is not enough time, you need to revise your estimates up (this project) and learn to be more conservative in the future (next project).

The responsibility of the project manager is to take these LOEs and put together a project plan which keeps everyone busy and makes the dependencies and high-risk items get developed first. It is, further, to track progress on tasks at the high level to make sure the overall plan isn’t falling behind (or, rather, to react properly and quickly when it does). This is plenty of work for the project manager; he shouldn’t be adding “question the engineer and pressure him to complete a 2-week task in 3 days”!

Now, all that having been said, you ALSO have to schedule time for “engineering projects”. That is, a project which does nothing other than fix the code you thought was good when you wrote it but have butted your head against six times in the last three months. There are no customer features here: this is an investment in all future features and performance. If your org can’t allow these types of pojects, again, it boils down to the Engineering Manager to “slipstream” such efforts into existing projects, although this only works to a certain level (rewriting the app in a whole new language is unlikely to get slipstreamed into the “Add non-blocking relationships between bugs” project).

Moving to an open source model, you probably don’t have anyone acting in the EM role, so all the above falls to the engineers. Seems like it all still applies though.

48

“we should also focus a bit more on things the customer will see and care about, and less on the things they never will”

Think of this scenario: What will answer children if you ask them whether to go to school or not? Or to wash their teeth or not? Many will answer they prefer not to. If you let them choose, many will choose the worst option, so if you change your ways depending on their choice, you also choose the wrong way.

Now, you ask a client to assign a value to a software product. And he’s like a child: he hasn’t knowledge enough (no “education”) to do it right; so, probably he will choose the wrong parameters to make the decision, e.g., “how pretty it looks”. If you support him because he and many people think the same, and you don’t realize they are unawared of what is really important in software, then you support this lazy-man way of making decissions.

Teachers teach children to understand the right way of living, and programmers should also try to teach: a car is not good because it looks good, only a fool would think that!

But it’s easier to go with the flow: I’ll give you what you ask for, without trying to teach you that you are wrong, and that a well coded app has better mainteining, etc.
Really, don’t you think that programmers should also be “teachers”, somehow?

I think you would’t say, as you do:
“and less on the things they never will”.
Beacuse this word, never, also depends on you, and how you teach your clients!

49

Jeff in reguards to:

The next time you’re knee deep in arcane language geekery, remember this: nobody cares what your code looks like. Except for us programmers. Yes, well-factored code written in a modern language is a laudable goal. But perhaps we should also focus a bit more on things the customer will see and care about, and less on the things
they never will.

This sounds like when your boss is pushing you to get your code complete. (You might want to right a blog titled “How a product manager can affect coding style”) But code complete is more than completing code. It is about being proud of what you do. It is about reading a book like “Code Complete 2” and putting those values into practice. It is true that the main focus on creating a program is to solve a customer’s problem. But what you do behind the scenes does matter. It will especially make a difference during the maintenance stage. Never let anyone take your style, if not they are taking your soul.

50

Bad code = (hard to fix bugs OR hard to implement new features)
= unhappy customers.

Simple.

51

The end user may only care about a pretty interface, but to get the pretty interface it is much easier to debug pretty code.

It is difficult to have a pretty application with ugly code behind it.

52

@Tom:
""I want the joints in my furniture to be well-made whether or not I can see them.“
Really? So you actually care about, for example, whether they used flathead or phillips screws in the joints? Or whether the frame’s sanded?”

No, but I imagine he does care about if the chair was built using oak or balsa wood. And, I do care about if my table is solid wood or micron-thin veneer when I go to refinish it.

More to the point: if the table being made was designed such that it needs a contortionist midget to screw the top onto the base, thus causing the factory to employ a fleet of contortionist midgets, thus raising the cost per table: I the consumer don’t care overly much, I just buy the cheaper table from the guy that designed it right in the first place. Similarly, if you are working on a bad foundation causing your costs to go up and/or your agility to plummet, your customers likewise won’t care nearly as much as they’ll just pick a different vendor for whatever it is you produce.

In any case, the car analogy is better (as cars need service far more than furniture, although less so than software it seems). Does anyone care about the metal used in the spark plugs? Well, if it is the wrong metal and causes corrosion, you as a customer might care, and I as a designer or mechanic sure as hell care.

Poorly designed software is precisely equivalent to an engine requiring a complete rebuild to replace a fan belt. To hand-wave this scenario away is to hand-wave the vast majority of poorly-designed software (and, thus, the vast majority of software, period) away.

53

I’m just wondering if, in 20 years time, people will be describing Ruby, Python, etc. in the same way they describe Perl today. I think the signs of doing it with Java and C are already pretty evident.

"Bad code = (hard to fix bugs OR hard to implement new features)
= unhappy customers.

Simple."

Code = hard to fix bugs OR hard to implement new features.
Seriously, name 5 mainstream products that’ve been constantly easy to fix/improve for more than 5 years. A definition of “easy” here may be a bit variable, but, for example, it does NOT mean, “I can do it, and everyone else is stupid.”

54

@Jim Cooper

i never said write crap code, what i was aiming at is dont always try to reinvent the wheel with new flashy architecture, using the project to test the lastest features.

This is what we as programmers like to do, we just need to remember that in the end there is a deadline (if there isnt then go for it.) and if we have to use an older style to hit that then although we might not like it, but that is what we should be doing.

I would never recomend that we dont use coding standards or write crap code. just dont always push for the newest flashest way toi do things cos you as a coder want to… the end result is what is important.

55

I couldn’t disagree more. The quality of the code directly affects the application performance, available features, the difficulty in addressing bugs and the ease and cost at which new features can be added. Users definitely care about those issues.

Further, bad code attracts bad programmers because the good programmers don’t want to be wasting their time working on junk.

A badly written working product of today might be widely used, but a well written product will inevitably overhaul the market leader in a fair market.

56

I would never recomend that we dont use coding standards or write crap
code. just dont always push for the newest flashest way toi do things
cos you as a coder want to… the end result is what is important.

Bit of a pointless argument though. I’ve never heard anyone suggest the end result isn’t what’s important. Is this even disputed?

But as a developer, the code IS important, and I like it to be clear, commented, indented, logically designed, not relying on magic numbers or dirty hacks etc etc. Maintainance is often/usually (pick one) more expensive than the coding was, and I’ve seen enough crappy code where the end result met the user’s requirements thanks very much.

57

@Tom

You’re right, I don’t check with the manufacturer about the metal used in the sparkplugs. However, I do assume that they’re correct. I also assume that the engineer has done a good job while designing the car.

Customers do the same when they buy your software from you. They believe that the people who developed the software and are now willing to charge money for it have spent some time designing it. Developers should spend time developing quality software, ie. software that delivers the customers requirements, is easy to maintain and enhance and is reliable.

58

You are absolutely right Jeff, end users do not care one whit about whether it’s written in Assembler or Ruby on Rails. All they care about is whether or not the end product satifies their needs.

This is of course how it should be. If you don’t build a product that sells then you don’t get paid, your company does not make money and you will find yourself on the un-employment line pretty quickly.

For us geekazoids, well, the language is everything. It is the tool that enables us to do what we do. To us, the journey is the reward.

But always remember, just like the homeowner who does not give on whit whether or not the carpenter uses a hand saw or a skill saw to cut the rafters, our users only care about one thing, the house that we build them. In their case it’s not the journey, it’s what’s at the end that counts…

59

Correction, in the above post I meant “If you build a product that doesn’t sell the you don’t get paid…”

So much for my own proofreading…

60

It’s not quite as simple as all this. There’s a delicate balance to be struck Jeff. Yes, you must meet the needs of your customers reliably and efficiently to be successful.

However in the long term business viability of your product you also need something that is cheap to maintain (shorter release cycles, smaller staff == more profit), something that is developed in a language that you can attract more talent too (larger talent pool == higher quality, lower costs).

I entered programming in 1998, when I was in college, they didn’t teach cobol and rpg. Yes there are still these systems in the wild but you honestly couldn’t pay me to work on them, I’d have to learn a dying language and it would do almost nothing to prepare me for my next job. These systems won’t necessarily be replaced because they are faulty, most are rock solid, but they will be replaced because it will be too damn hard and expensive to find people to work on them.