Slashdot Mirror
Software Aesthetics
cconnell writes: "Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame. This article is a challenge to engineers, managers, executives and software users (which is everyone) to raise our standards about software. We should expect the same level of quality and performance in software we demand in physical construction. Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty." We had a good discussion on a related topic half a year ago.
- Meet user requirements
Which doesn't necessarily mean it has nice and pretty code. If you have time, you are doing yourself a favor by designing it, but you can't lose track of the purpose of what you are doing, which is to get something working.Most techniques for designing or building software (e.g. patterns, processes) all serve to help you avoid bugs, which is to say more efficiently build software that meets user requirements.
http://www.naildrivin5.com/davec
The bridge analogy you mention is frequently quoted. And I agree, standards in software design & implementation need to improve - particularly in the shrink-wrap world (I happen to think that in-house bespoke systems are generally better). But the standard response to your standard analogy is that any non-trivial application is hugely more complex than a bridge.
The design of a bridge is basically the extrapolation of a few well known engineering principles to the scale you want. It has 2 requirements : (1) It must reach from one side to the other and (2) it must not fall down. You may have noticed that software is not like that
I remember reading a quote from a famous software scientist (I forget who, maybe Turing?) who said (and I paraphrase here) that we shouldn't be teaching our your computer scientists maths, physics, engineering etc, but rather art and biology. Because programming is an art, it's the creation of something from your own imagination, not like engineering which is simply applying rules. And once created, any large application behaves far more like a living organism than a machine, it grows, it evolves and (often) it gets ill. I always liked that idea
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
Personally, I found Donald Knuth's Literate Programming as well as the Practice of Programming to be wonderful resources for writing better, more beautiful code.
This article is very interesting; the idea of code as an art form isn't new, but this article certainly is aggresive in encouraging it.
But what about "Extreme Programming" - doesn't it encourage the same thing, in terms of self-commenting code? Or does its specific nature essentially negate that aspect?
I can't tell you how many software packages I've looked at that are ABSOLUTELY HIDEOUS on the inside (and open source isn't exactly immune to that either. Anyone taken a look at the code of SSLeay? Good package thou).
The problem being, however, that once you have money entering the picture, and/or time, then the first thing to go is code quality. Mind you, combine that with the fact that a few years ago anyone who had the patience to sit down and read "How to program in java in 21 days" suddenly became a programmer. Here at work we have a very large codebase that we originally contracted out someone else to do, then took over once we got more funding. They preferred the "copy/paste" approach to doing loops, and tonnes of other hideous hideous things. I've done things like cut down 2500 lines of code to 1100. In fact, the company here could save money in the long run by hiring me to do nothing but optimize, by the cost of additional hardware that they would have had to buy to support this. ugh.
Unfortunately, in the land of "80% complete is good enough" and where "as long as it works" is a good philosophy, and in a land where "visual basic" is a professional programming language, we're not going to see this improve any time soon. Even Java works squarely against the goal of "efficient". Give me C++ any day.
I think that another part of the problem is people just not caring about their code, not having pride in what they accomplish. That and people simply not knowing what the hell they're doing. (Not that I know ANYONE like that around here... nope nobody...)
Argh. Ok sorry, I'll end my rant now.
If God gave us curiosity
Typically, the user interface to software is supposed to look good. This corresponds to the visible stuff in a house: the walls, floor, fixtures, etc.
But does the wiring look pretty? Or the plumbing? Or the unfinished basement/garage? Or any of the stuff that actually makes the house work?
Hell no.
Does the engine of a car look pretty? It's covered in grease and all kinds of crap is sticking every which way, and it doesn't make sense to the non-initiated. Function is more important than form when it comes to making the car go.
I'm getting tired of these calls for purty code. I like an elegant piece of software as much as the next guy, but my manager could give a crap as long as it works, and in fact won't be willing to give me extra weeks to make it look nice on the inside. Particularly when you consider that I'm probably the only person who's really ever going to look at my code.
Monkeytreats
Attempting to compare software engineering to building a bridge or constructing a house is flawed. The reason bridges are built to such exacting standards is because if they aren't, they FALL DOWN. They cease to function. 100% failure. Poorly built software, on the other hand, can still work well enough to be usuable. It may imperfect at some tasks, but perform adaquately at others. If it were true that anything less than a perfectly engineered piece of software would simply fail to compile, then we'd all be writing perfectly engineered software.
An additional flaw in the analogy is this: The function, or use, of a bridge is quite clear: Extend a roadway over an otherwise impassable divide, such as a river. Simple as that. But deciding what the function or use of a piece of software is much more difficult and complex. Software is told to do many things, and the things it's supposed to do changes over time.
I'm all in favor of well designed software. But his vision is more utopian than useful.
That is why we have advanced software engineering techniques like eXtreme Programming. Through it's constant refactoring it makes sure that code is always the best it can be for the task at hand, and constantly improving.
The only reason that so much code is ugly is that most people do not know about and adopt XP. XP closely resembles the reality of Open Source programming in its implement-now mentality and constant addition of features. If everyone used XP, the software world would be a better place!
Even Slashdot wants to hide some things
Every extra day that I take to plan, every minute I spend thinking about design, and every extra line of code I write to make my software more pleasing is another line that could add more functionality, another minute wasted not producing something tangible, and another day that I need to be paid.
That is an absolutely absurd statement. Every moment spent in planning, review, consideration of potential problems, creation of general-purpose solutions, and documentation of architecture pays for itself many times over later in the development, validation, release and maintenance cycles. Failure to undertake sensible planning activities early in a project leads to massive schedule delays from forced late-game rearchitectures that would have been headed off by early consideration, review and communication.
Software engineering is the only engineering discipline in which the practitioners are permitted to indulge themselves in work without planning or review, and that's the #1 reason that software sucks.
Tim
Very perceptive...coding software is like crafting a cabinet. However, designing a cabinet is art...and so is designing software.
Try expressing an emotion in C++. It cannot be done.
jesus->loves(you); // Sarcasm, for the humor impaired
Regardless, art doesn't just express emotion, it inspires emotion. And trust me, I've had (mostly other people's) C++ code inspire some pretty horrific emotions. ;-)
Good design and coding, on the other hand, can truly be things of beauty, regardless of language.
Please think before repeating these banal opinions that software is art. It just isn't. Deal with it, and if you want to be an artist, learn to paint.
Spoken like someone who just doesn't really comprehend software design, or why one design might be more elegant than another. I suppose you don't think mathematics is beautiful either...
186,282 mi/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
The cited article doesn't say anything profound. (I got particularly worried when he said, "global variables and GOTO statements ... may be exactly what the software needs to marry form with function," and when his example of beautiful software turned out to be a fragment of Visual Basic. "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." --said, tongue at most partly in cheek, by Edsger W. Dijkstra, in "How do we tell truths that might hurt?")
... and there are other programs about which we can say, 'wow, who wrote this!'" He suggests how you can recognize software with The Quality: "every part of the code is transparently clear -- there are no sections that are obscure to gain effciency; everything about it seems familiar; I can imagine changing it, adding some functionality; I am not afraid of it, I will remember it." There are even suggestions, not how to make more beautiful software, but how to learn to do so.
Richard P. Gabriel (whose essay on "Mob Programming" was recently discussed on Slashdot) has a far more profound take on the subject. He has a summary of Christopher Alexander's work on architecture and "The Quality Without A Name," and how it relates to software; you can read the PDF version on his Web site, or Google's cached text version.
Excerpts: "there are programs we can look at and about which we say, 'no way I'm maintaining that kluge'
Gabriel helped start the "patterns movement" in the object-oriented community. Aside from the Design Patterns book, patterns (and especially generative pattern languages) have yet to make a significant inpact on software development. Maybe someday, maybe not.
Stupid job ads, weird spam, occasional insight at
I suppose that might be true, but I would venture that not everyone is in the same boat. I, for example, AM paid to write pretty code. My job is to come up with relatively simple perl scripts (modules) to solve various problems that Dartmouth's website users have. (For example, I wrote a quota module to help people verify that files they want to write to disk will fit within their alloted disk quota.)
I have NEVER turned in to my boss anything but well-documented, well-commented, readable code. I don't do this out of respect for my users; frankly, I know how to use the software and if they don't they can read my docs and try to figure it out. No, I do it for the other schmucks like me. At some point, my boss will probably tell his next lackey to add some little feature to one of my modules, as he's asked me to do with some older programmer's works. And it's DAMNED IMPOSSIBLE to wrap my head around code which is all mixed up. I comment for other programmers. People who might need to sink their hands into my code.
Paying me now to write comments and format things well is worth it for the added speed with which the software will be maintained in the future. So for me, and I'm sure most of the code jockeys on Slashdot, the "real world" is one where software is written, THEN MAINTAINED. Beauty is part of maintanence.
Its messy if you do not know what you are doing. Just like coding or debugging.
Biological systems are actually incredibly beautiful well structured, and in many cases optimized for their environment to a level unmatched in artificial systems. (I study vision and I see this sort of stuff all the time)
At any rate, the analogy to biological systems sort of works and sort of does not. Biological systems are not planned, rather they evolve (valid arguments accepted for religion. However, in human experience, biological systems evolve as we do very little in the way of planning outcomes unless one is making transgenics or cross breeding. Even then we are often simply along for the ride). Software too evolves, but well designed software is thought out and planned in advance with lots of end user input, subject matter expert input, and testing of code and interface to meet the users needs. In my experience with others code and commercial products, most software goes right into the writing phase with very little forethought or planning. "We'll get to that later" is the phrase I have heard again and again. The programmers that stay and get rewarded are the ones that can plan, work with subject matter experts, and listen and implement ideas and suggestions successfully. The ones that will not work long for me are the Prima-donnas that try and force their code down everyone elses throat saying nothing else will work. The reality is that either they are too lazy, or not talented enough and are unwilling to work hard enough to become excellent programmers.
I am seeing this more and more with the Microsoft way of writing code which is timeline driven rather than product driven. While being good enough for many, in reality it is third rate stuff without a commitment to excellence.
Visit Jonesblog and say hello.
DISCLAIMER: this is not a cheap shot at interns: it is a shot at managers failing to properly groom young hackers into veteran hackers with the humility to focus on the what's best for the project, rather than deft coding tricks.
i've seen dozens of interns and new hires come in with 1 or 2 semesters of C, and write lots of code, sometimes important pieces of code. management seems to think that if you throw enough newbies at a problem, it's the same as one or two really good programmers. this is a huge management oversight. interns and new hires need good solid mentors and time to develop and hone their skills, and project management needs to enforce design rules. unfortunately, newbies are very reluctant to code to design rules, I know because I always wanted to do stuff my way as an intern (eight years later I'm writing design rules... irony). the result is like a meatgrinder on full speed: code spewing everywhere that all looks different, and is not being tested, regressed or reviewed.
I've seen projects with strict design rules and rule checkers plus a technical guru/godfather for the project owner: results, fewer bugs and fewer people needed to support the code, and i'm talking about million line simulators.
solution: mentoring by veterans with large program experience (the really mean veterans, they are the best people to surround yourself with); and a strict adherence to design rules and revision control; and regression/coverage testing!
https://www.accountkiller.com/removal-requested
That's about the most naive blanket statement I've ever read. "its always best to have good code, not code that looks good."
Consider a project that lasts 5+ years. Over the life of the project, there will be dozens of developers added and cut from the payroll. Assume your "good code" gets executed once or twice a week and instead of taking 2sec it takes 1sec. You've saved 1sec (possibly 2sec) per week which adds up to 52secs (or 104secs) per year.
Let's compare that to the human maintainer. Assume one person has to look at that code 1 time every 6 months and it takes them 30 minutes to understand it. That's 60 minutes that someone is getting paid to understand that code.
If the person earns $80,000 US, that's about $4 (assuming 4 week vacation) that was spent on the human. It's actually less when you consider that a person's salary is not their labor rate. Over the life of the project (5 years) you've spent $83 on your "enhancement".
Now, if the cost of up'ing the Mhz on your CPU is greater than $83 then it may make sense to implement the "enhancement". However, when you consider the price differential between a 900mhz processor vs a 933mhz processor (the argument being that a 933mhz processor could run the slow code and keep up with the 900mhz processor running the fast code) you won't find an $83 difference. It'll be more like $20.
That being the case, humans are more expensive than computer CPUs these days. Maybe they weren't in the past, but they are today.
Another argument for clean easily-readable and understandable code is that, if you take your argument, the entire system will become "enhanced" and no one will understand how it works. That will add on an additional overhead in the form of lack-of-enthusiasm for a project and will have financial implications.
All in all, I've worked on XP projects where code formatting and understanding was important. And I've worked on government contracts where people hack'ed their way through to save a couple of cycles. Maintainability speaks volumes... And I'd go with readability and understandability in a heartbeat...
For a particularly good book describing the problem and situation (fabulous for understanding the flaws in most businesses software design methodology, and more importantly for convincing managers that this is the case) then you should read The Inmates are Running the Asylum by Alan Cooper, the 'Father of Visual Basic' and also author of About Face: The Essentials of User Interface Design .
It's light on concrete solutions (although the foreward addresses why that is the case) but still a useful primer to read even if you want to solve the problem, since the first step to solving a problem is properly understanding it. It's so fabulously refreshing to see in print a rather respected person describing the problem as I know it to be true, and especially providing big-business, big-name, concrete examples to point to and say, "SEE! IT REALLY DOESN'T WORK TO SET ARBITRARY DEADLINES AND TO START CODING WITHOUT PROPER SPECS!".
This issue is just a little bit important to me :)
Beauty isn't really the issue here, it's maintainability. The current project I'm on, I 'inherited' someone elses butt-ugly code. It did the job fine, but I spent the first six months reading, re-reading, and testing, just so I could understand what the thing was doing. All told, I spent over a year just getting comfortable with the program. Meanwhile, I'm also supposed to be updating this thing for a new release every six months! Every chance I got I did 'code clean-up', fixing things that worked, but were difficult to understand the logic of, or just plain stupid (take a long, often-used routine, and make it in-line everywhere rather than use a function!?).
Finally, after two and a half years, I get the chance to re-write the whole thing into Java. (I know, it wouldn't be my first choice, but ANYTHING beats Powerbuilder!)
The point is, unless you are writing 'throw-away- code, your program may exist for many years, and have many people maintaining it. We need to do ourselves a favor and make sure that we can understand what we all write. Memory is cheap, so there is no good reason not to write good, clean, easy to follow code.
And don't give me the argument that "we're up against deadline". I've been playng this game for twenty years, and I know that every minute I spend in the design phase is like an hour saved in the coding phase. Design the thing first! Make sure you know how it is going to break down into the various modules you will use. If you design it right, the code will flow, and you will make your deadline easily.
I know, all you young hotshots out there won't listen to an old fart like me, but eventually you will either learn the hard way that I am right, or you will burn yourselves out and never want to code again. Meanwhile, _I_ get stuck trying to maintain the crap _you_ wrote!
We gotta make democracy safe for the world! -- Pogo