Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Should Write Ugly Code

redotheweb.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: You Should Write Ugly Code

#31

Post by amouat »

doktrin wrote: post #30
Swizec wrote: post #2

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. Relevant blogpost: http://swizec.com/blog/my-very-own-daily-wtf/swizec/5829 Relevant website: http://thedailywtf.com/

What you're describing sounds more like the result of poor test coverage. The OP was mostly referring to design patters and a semi-arbitrary measure of "beauty", not specifically advocating writing unmaintainable code.

I would argue "beauty" in code is very strongly linked to maintainability.

Re: You Should Write Ugly Code

#32

Post by ricw »

planetjones wrote: post #24

Disagree. 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. 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 y…

Absolutely correct. And what clean code leads to is more maintainable and more easily update-able code. Beauty or ugliness is absolutely not a feature. Its a sideline to what clean code is.

Maintainability is totally the high order bit here. And its totally worth getting it right (or at least approximately). Its the anti-thesis to ugly code.

Re: You Should Write Ugly Code

#33

Post by samdunne »

> personally think that developers shouldn't care about code beauty, because that's not their job.

I believe anyone else on your team will waste a lot of time and effort figuring out the spaghetti code you wrote.

Think. Then code.

Re: You Should Write Ugly Code

#34

Post by Swizec »

amouat wrote: post #31
doktrin wrote: post #30

Earlier quoted context omitted.

What you're describing sounds more like the result of poor test coverage. The OP was mostly referring to design patters and a semi-arbitrary measure of "beauty", not specifically advocating writing unmaintainable code.

I would argue "beauty" in code is very strongly linked to maintainability.

I would argue it's the same thing.

Re: You Should Write Ugly Code

#36

Post by jt2190 »

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."

Re: You Should Write Ugly Code

#37

Post by tsahyt »

planetjones wrote: post #24

Disagree. 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. 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 y…

I agree with you disagreeing.

The article really blurs the line between mere code formatting, which can be completely automated to adhere to some guidelines, coding paradigms and software design/architecture.

I'd argue that, for a product that needs to extendible and maintainable, well thought-out software design is at least as important as working code. It takes a bit more planning up front, specifying the system to be developed in terms of well-understandable and well-documented patterns but this time (and hence money) is not lost. It pays back double during both the initial implementation and maintenance.

A well thought out software design takes a lot of tasks off the people who go to implement it. It clearly specifies which parts are to interact and how they can be expected to behave. Therefore it fosters modularity and independent development of modules, which speeds things up and makes maintenance and extending the product easier. And that is what we really want after all. We want to get code and therefore products out quickly, we want to avoid bugs, we want to make sense of the whole thing after a couple of months have passed in order to implement NewFeatureX™.

There are numerous approaches to this. Object-orientation is just one way to do it and sometimes it's not the best way. After all, all these paradigms and schools of thought are but tools to get the job done and as always, it's a good idea to chose the right tool for the job.

The other thing is actual code "beauty" (however one may define it), which ultimately means readabilty. This is important too but it highly depends on what people are used to. That's why there're often coding standards for a given project or a company. Everybody gets used to them and no one needs to rethink when reviewing the code of other developers. There's no better or worse there. The only thing of importance is that it shouldn't be possible to pinpoint who exactly wrote a certain piece of code by just looking at it. If it looks like you wrote it, you'll understand it that much easier because it takes all the burden of messing with strange-looking syntax away.

The "just-get-it-done" approach to software engineering just doesn't work for projects of a certain size. That's probably why we call it "engineering" in the first place.

Re: You Should Write Ugly Code

#38

Post by planetjones »

ricw wrote: post #32
planetjones wrote: post #24

Disagree. 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. 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 y…

Absolutely correct. And what clean code leads to is more maintainable and more easily update-able code. Beauty or ugliness is absolutely not a feature. Its a sideline to what clean code is. Maintainability is totally the high order bit here. And its totally worth getting it right (or at least approximately). Its the anti-thesis to ugly code.

That's exactly what I was trying to say: "beautiful code is a byproduct of clean code". Clean code is the important part. Thank you!

Re: You Should Write Ugly Code

#39

Post by jiggy2011 »

ronjouch wrote: post #23
jiggy2011 wrote: post #11

This all sounds great, but I've worked in places where this has been the philosophy. 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. You will often meet the attitude of "well it works now, why waste time rewriting it?" or "sure, do that. But let'…

Thanks, "Technical debt" is the word here. "Beautiful" might not come close to "valuable" in terms of importance, but "Clean" should come close, because accumulating too much crap makes maintenance & feature addition painful. Uncle Bob's "Clean Code" does a great job at detailing that.

How does one define the difference between "Beautiful" and "Clean"?

Re: You Should Write Ugly Code

#40

Post by gicmo »

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.

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.

Post reply on HN