You Should Write Ugly Code

Disagree.<p>You deliberately call it beautiful code, whereas in reality it is clean code. Clean code is not more expensive to deliver than ugly code. It just requires a better calibre of developer i.e. a developer who can express features in a style which others can understand.<p>Once you have clean code you can take on features more easily and quickly. You can also change personnel more easily. Most importantly of all you can get better confidence that changes won't introduce side affects.<p>The problem is there are not many people who can do this.<p>No-one in their right mind (Fowler, Uncle Bob, included) say code should be beautiful as some kind of vain exercise in style over substance.

We shouldn't write maintainable code because the idioms might not seem fashionable at some point in the future? Never mind that code is read way more than it's written and that maintenance costs way more than development. Building up massive technical debt is fine in the short term but eventually you'll have to address it and that's going to cripple development on the product. OOP principles aren't a fad, they're fundamental to structuring code in PHP.<p>The analogy with the furniture is particularly misleading. Would you pay half as much for a chair that occasionally falls over? That takes a long time to get repaired because each of the legs is tightly coupled to one another? I'd rather pay double for the reliable version.<p>I've worked with a lot of code bases in the past where the developers have had a resentment towards new methodologies and saw people who tried to use new ideas as just trying to show off. It's a disheartening experience to want to use such fashionable concepts as 'objects' only to be told that the way things are done is procedural programming with SQL queries nested in markup like it's 2000 again. In my experience it's been because they've not wanted to invest in learning new things. That's not a good ethos for a programmer. Let's not promote it.

This all sounds great, but I've worked in places where this has been the philosophy.<p>Unless you have somebody in charge who understands the importance of code quality (and why a bad codebase can be a ticking time bomb) you will find it very difficult to budget time/money for the removal of technical debt.<p>You will often meet the attitude of "well it works now, why waste time rewriting it?" or "sure, do that. But let's clear this milestone first", "oh, priorities have changed we <i>need</i> to add this new feature first".<p>This usually gets externalized to developers who end up working excess hours firefighting a horrific codebase or implementing a bunch of features twice, once in the clean codebase and once in the dirty one.<p>I've had times where I worked 8 hours at work and then came home and worked another 6 getting the new codebase in sync to a point where it could be replaced.<p>And when people start loosing money because shit is falling apart due to a tangled, buggy codebase without proper tests guess who's ass is on the line?

Maintainability and technical debt are very real metrics. It is just question of short-term versus long-term investment. This article prefers short-term investment (as many other startups do). I just wish buyers would include code maintenance costs when evaluating start-up.

You should definitely write ugly code. People pay me and people like me good money to come in and clean up your mess when adding features becomes an endless exercise in breaking things in unexpected ways for the whole team and productivity plummets.<p>Relevant blogpost: <a href="http://swizec.com/blog/my-very-own-daily-wtf/swizec/5829" rel="nofollow">http://swizec.com/blog/my-very-own-daily-wtf/swizec/5829</a><p>Relevant website: <a href="http://thedailywtf.com/" rel="nofollow">http://thedailywtf.com/</a>

&#62; <i>Would you be willing to buy a piece of furniture twice the normal price because the craftsman uses the most expensive tools available? And what would you think of a poor craftsman who, using poor equipment, manages to create great furniture? Who's the best craftsman of the two?</i><p>The author forgot to mention most likely alternative here: a poor craftsman uses poor equipment to create poor furniture that breaks easily.

Yes yes, "True artists ship". In general though I would say that you can and should strive both for end-user value and overall systems quality.<p>I agree to a point - the pattern du-jour has little to do with good code. I also agree - to a point - that prototyping should produce results as fast as possible. It's very hard to create something new and novel without rambling prototypes. You need those to feed your intuition on what aspects are critical and what are not.<p>As a general guideline, though, this is horrible advice. Although it depends on the definition of "ugly". I would pragmatically define beautiful code as something that is as simple as it can be to implement a useful set of end-user functionality, contains only acyclic dependencies, obeys the key-rule of DNRY (do not repeat yourself), is buildable using a single developer action, is preferably automatically deployed ... and so on and so on.<p>The key metric to beautiful code in my opinion is that the code and it's host system is in every way as simple as it can be. Sometimes you need a few abstraction layers to simplify the total complexity, often you don't.<p>It's not just the code. It's how it integrates with the rest of the world that matters. The integration points can be productivity multipliers for the organization.<p>And, as a developer, you can learn all the time. The better systems you build, the better the next system will be (unless it happens to be the second system where you traditionally must try to implement something horribly baroque). You have to be learning constantly to grow as a developer. You have to consciously strive towards simplicity and elegance, because otherwise you will get stuck. If you accept bad code as "good enough" always, I fear you will not grow up to your full potential.

It is only me who noticed that average level of intelligence of participants is quickly approaching that one of /b/?)

The article mentions design patterns, dependency injection, procedural programming, OOP, and all sorts of techniques that aren't categorically "beautiful" or "ugly", so it's really hard to know what point it's making, other than "don't spend time doing work that has no clear benefit."

I am currently working in a environment, i.e. computational neuroscience lab, where getting results quickly is the most important thing and nobody really cares about the aesthetics of the code, heck not even about the resulting program (the "product") created by that programming. We therefore do indeed often write "ugly" and somewhat unclean code.<p>I can assure you that I have been angry about (my own and others) working but ugly code more often than not, because at some point you lose control and then you don't even understand what is going on anymore. Try making another 'quick' modification to the source base then. Oh and don't forget the fun to read some other PhD student's (scientific quick hack) code, who isn't even in the lab anymore.

This article is attacking a very narrow and superfluous definition of beauty, that I would instead call fashionable. The beauty of a piece of code should depend not so much on how well statements are aligned and consistency of formatting, and more on how easy it is to understand; the complexity of the task in contrast with the simplicity of the program.<p>That said, I still take issue with criticizing his narrow definition of code beauty. We should be allowed to dote on our code and make it pretty. Even if it doesn't provide tangible value to the customer, it lets us take pleasure in our craft.

Why shouldn't I take pride in my work?<p>&#62;When facing an implementation choice, should a developer opt for solution A, which uses ugly code, or for solution B, which is beautiful? That's not the right question: from the end user's perspective, the alternative doesn't make any sense. The user won't look at the code, especially if the product is not good enough to be even tried.<p>"Let us do our work as well, Both the unseen and the seen;" - Henry Wadsworth Longfellow, The Builders<p>You can write ugly code that works or you can write beautiful code that works. You can't write beautiful code that doesn't work.

beautiful code <i>does</i> work in shipping products. This article is just designed to stoke a flamewar. :/

I agree with the article because the code many people consider beautiful does not mean easy maintainance.<p>We want clean and simple code, not anything with convoluted patterns.

If you are writing code for aesthetic purposes of course you are doing it wrong. If you are writing code and balancing delivering features with maintainability. A balance that constantly changes. Then I would argue you are doing it right. Sometimes that balance is just deliver for the deadline, nothing else matters. Sometimes it is this needs to be extensible and maintainable because it's a cornerstone of our product.

If you still think that design pattern X is fundamentally better than design pattern Y, Z, Carrot, or Potato, you're missing the point. The point is to have something consistent that works. Design patterns reduce the mental load on the maintainer. The point isn't beauty for the sake of beauty, though it does feel nice to have something that is beautiful.

Cannot possibly disagree more.<p>- Of course, ugly code is fine for experimening, short-lived code, or code that won't be touched again.<p>- But beautiful code makes me enjoy my work, which is <i>really</i> important.<p>- It makes lives of other devs better. Devs want more money for working with ugly code (ie. it costs the company money).<p>- Ugly code supports the culture that aesthetics is not important.

&#62; the code they wrote for the sake of beauty is crap.<p>From my understanding, this is the crux of the article. The problem with this is the misunderstanding of why people employ patterns in programming. It's not for the sake of beauty, but because of sound architectural principles.<p>Maybe that's how he interprets beauty, but then using the word beauty diminishes why the code was written the way it was written. That beauty is subjective.<p>The reality is good code and good practices have real measurable value that mere "beauty" does not.

&#62; personally think that developers shouldn't care about code beauty, because that's not their job.<p>I believe anyone else on your team will waste a lot of time and effort figuring out the spaghetti code you wrote.<p>Think. Then code.

confusing clear code with pretty code is just as wrong as confusing good design with pretty colors<p>edit: reworded slightly

With so vague definitions, this article is uninteresting without a single example.

There's only one true brace...

50% of the product is the code base in which you iterate on and add new features.

I had a really great post for this topic about the utility of ugliness in language design. Ocaml provides imperative features but makes them ugly, subtly encouraging a functional approach in most cases. Clojure quite brilliantly makes OOP and heavy Java interop possible but very ugly (because the language's ultimate goal is platform-agnosticism) while making idiomatic Clojure beautiful. Making something ugly is often more powerful than saying "don't do that". So ugliness has a real value, and that's what I originally came here to talk about.<p>Then I read the OP, which had to go and ruin that by being wrong.<p>First of all, OOP is not "beautiful". Quite the opposite, I find Delegates and Factories and Visitors to be fucking atrocious from an aesthetic perspective. All that stuff is there to make business people think their metaphors apply to code and to give them a sense that they, the "big picture guys", have a chance at understanding what's going on. They don't.<p>I've taught. I've designed games. So I understand the importance of aesthetics in any replication process. Making something easy to learn, understand, replicate, use, et al actually comes down to aesthetics. Now, it's <i>a specific kind</i> of aesthetic sense you need. You spend more time on convergent creativity (trimming, simplifying) than on divergence (adornments, gargoyles, "neat" advanced features). You should, at least when you start, ship a simple product that people can use rather than a complex one that you (having grown up with the complexity as it emerged) find "beautiful". With that I agree. It's better to write straightforward "boring" code that works than to apply every programming trick in the book (self-modifying code! three-level syntax quoting!) If the dumb thing works, use it. Complexity will happen on its own, so don't go looking for more.<p>Not paying attention to code aesthetics and simplicity, however, is a recipe for disaster. If your code is going to be read by other people and you write ugly, unmaintainable code, then... well, good luck with that.<p>I don't really mind the substance of what the OP is saying (focus on solving problems rather than writing code) but the presentation is awful.