![]() |
Sponsored Link •
|
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.
Have an opinion? Readers have already posted 13 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Alberto Savoia adds a new entry to his weblog, subscribe to his RSS feed.
![]() | Alberto Savoia is founder and CTO at Agitar Software, and he has been life-long agitator and innovator in the area of software development and testing tools and technology. Alberto's software products have won a number of awards including: the JavaOne's Duke Award, Software Development Magazine's Productivity Award, Java Developer Journal's World Class Award, and Java World Editor's Choice Award. His current mission is to make developer unit testing a broadly adopted and standar industry practice rather than a rare exception. Before Agitar, Alberto worked at Google as the engineering executive in charge of the highly successful and profitable ads group. In October 1998, he cofounded and became CTO of Velogic/Keynote (NASD:KEYN), the pioneer and leading innovator in Internet performance and scalability testing. Prior to Velogic, Alberto had 13-year career at Sun Microsystems where his most recent positions were Founder and General Manager of the SunTest business unit, and Director of Software Technology Research at Sun Microsystems Laboratories. |
Sponsored Links
|