Software Best Practices

Start the disuccsion here!

One of the things that struck me in the first two chapters (and a bit implied in the third) that beautiful code is the result of an individual mind thinking by themselves to come up with the great design/code. This seems contrary to the teamwork ethos we see in things like Agile where the tough issues are solved by more than one head working on the problem.

So my questions is, is "beautiful code" more something of a solo act or can it be achieved by teams? Which is the more likely route?

I'd agree that it is a solo act in the the first chapter. I think what struck me was in all three cases you have examples where a domain expert came up with the solution. The old expression "nothing beats experience" really strikes true in all these examples.

The Regular Expression example is really neat. It's a very good example that if you constrain your requirements to meet the most useful use cases you can write small, elegant and easy to understand code. I also agree with the author that it's a very nice use of recursion and I like it as it's another source of questions I can ask in Interviews :-)

Subversions Delta Editor is another good example of applying constraints to your design. The decision to limit the traversal order to depth first makes the problem much, much, easier to solve. I'd disagree that this was solved by one person. What I'd be interested in is how much time did they spend talking to Jim Blandy about their approaches, blind avenueus, etc? I'm of the mind that often design is about looking at the different alternatives and picking the best one. In this case it looks like there was an alternative they didn't consider, but the amount of work looking at and rejecting the others was probably a significant factor in the end design.

It's also nice because once I'd read the code (albeit several times) the concept is easy to understand. It has that immediate "wow that's neat" factor to it.

 I'll end with saying I think that beautiful code can be achieved by a single person but beautiful design is something that needs to be done by more than one person. You need at least a few other people to bash ideas around with, get different perspectives etc.

Hi Guys,

I'm behind on my reading, but I did do chapter 1. I was immediately struck by the fact that the beautiful code was possible mainly because of the decision to limit the solution. It really makes sense to me, at this point in my career, to carefully choose which requirements NOT to implement. And although I have only used recursion once, for real, in any designs of my own (I work in embedded systems, so there is usually really limited stack space), there is nothing more beautiful when used right.

Earl Beede:

So my questions is, is "beautiful code" more something of a solo act or can it be achieved by teams? Which is the more likely route?

Well, can you think of a piece of art which was the result of a committee? And before someone says "architecture", remember that the actual appearance of a building is the result of singular vision. Beauty is nearly always the result of singular vision, even if the visionary depends on others for execution.

That points out a different divide, that between form and function. Code cannot be separated from the purpose for which it exists (well it can, but what's the point of that?). Lexx and yacc  generate completely horrendous code which performs a function elegantly. Does making code "beautiful" miss the point, since it is something that will only matter to other engineers?  I have no opinion here yet, just throwing out questions.

Kevin:

Does making code "beautiful" miss the point, since it is something that will only matter to other engineers?  I have no opinion here yet, just throwing out questions.

I do think there is a point to making code beautiful beyond just impressing other engineers. I think it is next to impossible to create beautiful code without a beautiful design. The effort that goes into making beautiful code encourages all the good stuff in designs: efficiency, clarity, priorities.. And this is going to lead to easier testing/maintaining/etc. and this is going to lead to happy customers. These customers may not know they are happy because their systems contain beautiful code, but they will be happy.

Susan:

I think it is next to impossible to create beautiful code without a beautiful design.

I thought about this one overnight before coming up with my considered reply:

Hooey.

This conflates construction and design. It is more than possible to have a beautiful function, class, whatever, as part of a crap design. Which is not to deny any of the qualities you list as part of good design. But good design does not even guarantee code that looks good with beer goggles on.

Besides, wouldn't it be the other way around? Good stuff in designs encourages beautiful code, not the other way around.

I clearly spent too much time on the debate team in high school and college, I'm a born Devil's Advocate. Or is that born again? I never get that straight.

Kevin

Man, do I know how to clear out a party.

To this point, I must say that there is little I can draw from this book that will improve my work practice.

What about all of you? 

Maybe this book is more like going to an art museum. You look at it, say "nice", and move on. Does it really impact your daily life? It gives you something to consider as you write your code, that something is better out there.

My main thought so far is, "so what?" I mean, so the code is beautiful. Does it solve some problem for the customer? What were the requirements that drove that code? I think critical requirements are satisfied in design activities, not code.

Maybe we need to move on to the next three chapters.

Been a bit busy lately and I actually read these chapters a few weeks ago so had to skim read them again just to refresh myself :-) 

Chapter 4 - nothing to discuss. 

Chapter 5 - more interesting. Here is a good example of a reason to optimize and a nice example of each of the stages.

Chapter 6 to me is the most interesting. It's a non obvious design choice - keep the framework open and let people do what they want with it. Like the author says many experienced developers would say "I'd never write code like that". But it works and fulfils it's requirements? So really is there anything wrong with FIT? Can what looks like bad code actually be a reflection of a good design? 

Hi,

It may be a bit out of topic, but could someone please name the Author of the book, so that i could also join...

Thanks in advance,

ani

 It's a selection of articles from different authors. Here's a link to it though 

I got to read these chapters over the holiday weekend.

Actually, I thought the chaps four and five had a similar message in that there is some trade off between programmer and program reader and user time. Chapter four's emphasis seemed to be that, by its nature, some languages are more beautiful because they create easy reader, beauty from the eye of the program reader. Chapter five looked at the trade offs between programmer time and use time. I think it defined a sort of beauty from the programmer perspective.

Chapter six can be seen a bit in that light as well since it sees beauty in what the user can do.

So, the question is more who's eye is the beauty?

 I vote we move onto a new book. It's impossible to have a debate of any kind over this one. Who am I to disagree with any of these people?

"It's beautiful."

 "Is not"

"Is too".

"This isn't an argument, it's contradiction".

 "Is not"

I have to admit that I am not that inspired about the book either. Yes, it is hard to debate. It was also hard for me to really get into. Maybe I didn't read far enough but I found it easy to find something *else* to do rather than pick up the book!

So I am all for finding another book where my interest will be enough to ask you all interesting questions and we can have a meaningful debate.

Two books could be good for discussion. Both are by Robert Glass who wrote a column for Software magazine.

Facts & Fallacies

or

Creativity 2.0 

http://www.amazon.com/Facts-Fallacies-Software-Engineering-Development/dp/0321117425/ref=pd_bbs_11?ie=UTF8&s=books&qid=1199908768&sr=8-11

 I haven't read either but found is column thought provoking and a good read. 

I liked Glass's column as well. I would be happy to read Facts & Fallacies.

I waited a bit to see if there were other suggestions or more interest in reading this particular book.  I ordered a copy and will have one in a few days.  The table of contents can be viewed on Amazon, http://www.amazon.com/Facts-Fallacies-Software-Engineering-Development/dp/0321117425/ref=pd_sim_b_title_1

 I've never done this before so I'm not sure how we want coordinate our progress through the book.  

The good thing is that this book is about the best practice topics discussed in this forum.  The easiest thing might be to simply post topics from the book in the appropriate forum as we read them.  This way anyone can discuss them with, or without, the book. 

Of course, we could agree to read a chapter every couple of weeks too.  Either way is good for me. I'm open.

Regards,

Talman 

Hi Taman,

I am trying to hunt down my copy. When you read the first couple of chapter, start a new thread. Probably best under Methods & Process. If I beat you to it, I will start a thread.