Summary
In Part I we ask the question: "Is there a place and opportunity for truly beautiful code and programming pearls in real world of legacy applications and enterprise software?".
Advertisement
You are a bright-eyed and bushy-tailed developer. You have just finished reading the book Beautiful Code and you are ready to create some binary beauty of your own. You can’t wait to put what you’ve learned into action. You fire up your IDE and, as the blob of code that you’ve inherited and have to work with slowly loads, the brightness in your eyes is replaced by a glazed look. A minute later your bushy tail hangs limply in defeat. Reality sets in. Beautiful Code goes back on the shelf, next to Programming Pearls and Six-Pac Abs in Seven Days. You drink a sip of tepid coffee, sigh, and start hacking at the blob of code with the same level of energy and enthusiasm commonly displayed by those people in orange vests who pick up litter on the side of the highway.
The two most common comments I’ve heard on the topic of beautiful code, following the release of the book, go something like this:
Comment 1:
“I have read a few chapters of Beautiful Code. It’s a great book, but in my job I have to maintain a steaming pile of legacy code. I don’t have many opportunities to think about beauty because I barely have time to keep the existing code functional. The best I can do it to keep crappy code from getting worse.”
Comment 2:
“Very interesting book. I wish I had an opportunity to think about cool algorithms for tough problems, but I am working on a boring enterprise application. I read stuff from a database, do something trivial to it and then I generate some reports. There aren’t that many opportunity for clever algorithms and beautiful solutions in business logic.”
It’s easy to sympathize with, and understand, both comments. The odds of finding truly beautiful code in most production systems seem to be on par with the odds of finding a well-read copy of IEEE Transactions on Software Engineering in Paris Hilton’s apartment. Furthermore, enterprise software, which represents the bulk of code in existence, deals mostly with forms, reports, etc., which – one might argue – seldom require much thinking or cleverness.
Let’s face it, the majority of code that has to be written does not offer chances for the kind of beauty and cleverness that would earn it an entry in Beautiful Code – Part II. For every opportunity to implement something cool and clever, like MapReduce (see Chapter 23), there are hundreds of blue-collar pieces of code that have to be written or maintained.
Does that mean that you should stop thinking about beautiful code in your day-to-day programming? Should you save those lofty ambitions for your after-hour pet projects – or abandon them altogether? Of course not!
The opportunities for creating a true masterpiece of coding worthy of sharing and bragging about may be rare, but you have dozens of chances everyday to make the code base you work with more beautiful – even if you are stuck working on a mortifying morass of legacy code. That’s what my series of blogs Beautiful Code in the Real-World will be all about.
In the next few days and weeks, I will use these blogs to share with you thoughts, strategies, and ideas for creating beauty in everyday production code – even if that code looks as if it fell off the ugly tree and hit every branch on the way down.
Make sure you come back for Part II – Scorn globally, act locally.
The Real World has some monster code-bases - I'd like to suggest you address how "beauty" can be applied in the large, not just to snippets, algorithms or class-level patterns.
> Can COBOL be made to be beautiful? My feeling is that it > should be stuffed in a sack, beaten, weighed-down and > tossed in the ocean.
James, please don't be so sublime. What's your real opinion of COBOL? ;-)
Okay, onto an actual point and not directed at you James. Do experienced COBOL coders - and I'm not - find each others' code more and less beautiful? I find more and less beautiful C coding. I'm looking over Scala examples now and I find some that are elegant; consequently, the elegant ones are influencing how I'm going to approach use of the language. There's certainly more and less elegant SQL. When I was a DBA I had to review a lot of SQL; there are few developers who really use it well. My point is that there's certainly a subjective element influenced by what you're used to.
This is certainly a topic that waxes philosophical and draws us into discussions on Relativism.
> Do experienced COBOL coders - and I'm not - find each > others' code more and less beautiful?
There's definitely a 'right' way to do COBOL and a 'wrong' way to do it. Probably the worst thing about COBOL is that it allows for really bad approaches. But even the good COBOL looks like crap to me. You can either repeat yourself a billion times or make things opaque. Sometimes you have to compile it to clearly see what it does.
> There's definitely a 'right' way to do COBOL and a 'wrong' > way to do it. Probably the worst thing about COBOL is > that it allows for really bad approaches. But even the > good COBOL looks like crap to me. You can either repeat > yourself a billion times or make things opaque. Sometimes > you have to compile it to clearly see what it does.
I haven't had to support COBOL for 15 years and, even then, I only had to look over code to pull out SQL statements. It's a tool I've intentionally stayed away from.
So, it seems like within a language there is elegance/non-elegance but viewed in a wider scope, there's a progression in languages towards greater possibility for "beauty". Perhaps the ephemeral trait is greater abstraction giving a possibility for greater conciseness of expression with less verbosity?
> So, it seems like within a language there is > elegance/non-elegance but viewed in a wider scope, there's > a progression in languages towards greater possibility for > "beauty". Perhaps the ephemeral trait is greater > abstraction giving a possibility for greater conciseness > of expression with less verbosity?
I read "Hackers and Painters" not long ago and enjoyed it. I found myself agreeing with him quite a bit.
As far as language development goes, it's not only having the right ideas but having them at the right time. (Kind of a generalizable principle.) IMO, expression of ideas has become better. However, it's all still dependent on the developer. Unskilled developers are still going to write ugly code no matter the language. (An unskilled bike rider is still going to look clumsy even with training wheels and crash equipment.) Part of becoming skilled is a desire to do so and part is having skilled people to learn from.
50% of enterprise software is crud (Create, read, update and delete; pun intended). The book beautiful code has none of that.
I will be impressed the day somebody finds a beautiful way to create an interactive GUI front-end to correctly (keeping the business rules) manipulate views (consistent with the POV of different users) of a database. Bonus points if the solution scales properly.
The other 50% of enterprise software transforms data from one obtuse format into another to avoid having to manually type information taken from one proprietary application into another. Big companies unable to write all software themselves have hundred of those.
That is also a reason why most software written in house is not very reusable. Specific utility UI screens developed against “Acme loan processing database” and a data transformation program that allows to import client data from “Bambi client manager” into “Maxbeta billing system” is not very useful unless you just happen to own that software.
Creating and keeping anything beautiful comes with a price. I think source code is no different. Most of the time people settle for better than average. A Lamborghini looks beautiful but I can't afford it (yet :). I settled for a nice looking Grand AM. They are plenty of shops that offer maintenance service for it at a price I can afford. I see the source code the same way. My 2 cents.
> I will be impressed the day somebody finds a beautiful way > to create an interactive GUI front-end to correctly > (keeping the business rules) manipulate views (consistent > with the POV of different users) of a database. Bonus > points if the solution scales properly.
There are a number, which do it correctly; beauty is another issue. I prefer Andromeda.
MDA/XBML/foobar are all built on the notion of "abstracting" away from source syntax to something higher/else. The FOM is XML; using the system catalog is not really different. The difference is in the expression. If one believes that xNF is the true model (and I do), then it's same/same. OTOH some, as the RoR folks, assert that if you have to resort to source code generation, then your language is semantically wrong.
I read stuff from a database, do something trivial to it and then I generate some reports.
Sentences like this indicate that the programmer still has a positive identification potential with the program he writes. Otherwise he would say:
The program reads stuff from a database, does something trivial to it and then it generates some reports.
Note the change in perspective which is usually just applied when the evil program goes wrong and the I + program unity dissociates.
But keep it positive and assume that once the program does all the stuff and the meta-program contains the configuration / adaption instructions the man in the orange vest can garden the flowers on the wayside most of his time. That's why Paul Graham is right. A "great hacker" is by definition a person that rather prefers doing a different job than working with tools that won't bring him to his limits. And he will do different things along his daily work anyway - not necessarily gardening but maybe researching?
Previous Topic
