Tuesday, June 5, 2012
Architecture according to Uncle Bob
"a good architecture maximizes the number of decisions NOT made"
Friday, May 4, 2012
The nightmare of refactoring
I am watching the series "Clean Code". Episode 6 on Test Driven Development describes a nightmare scenario for refactoring that is so close to heart, that I just have to quote it here.
"Have you ever brought up some code on your screen that was ugly? And the first thought through your head was, 'Wow this is ugly, I should clean it'? And the next thought in your head was: 'I'm not touching it'. Because you know if you touch it, you'll break it, and if you break it, it will become yours"
"Sometimes the mess gets so bad, that we contemplate a dedicated effort to clean it... At first our employers might even support this idea. ... But cleaning code is hard and fraught with risk. When we clean a module, we have no way of knowing that that module still works properly. Perhaps we've introduced subtle bugs, or race conditions, or data corruptions. The more we clean, the riskier the situation becomes. The ad-hoc manual tests we've been running to make sure that the system behaves properly, begin to fail for reasons we can't easily explain. We start to debug and the debugging time grows, and as it grows, it eats into the time we thought we'd have for cleaning. After weeks of cleaning and debugging, we finally run out of time, and although we've done a lot less cleaning than we wanted to, and a lot more debugging than we'd hoped, we think the system is at least a little bit cleaner. So we hand the new "cleaned system" to QA... And unfortunately they return with a huge pile of defects. These defects are daunting, they contain inexplicable behaviors, data corruptions, even crashes. The list of new defects is so long and so puzzling, we don't even know how to estimate
how long it would take to repair it. After much wailing and nashing of teeth, we finally conclude that the only sane action is to set the "clean system" aside, and to revert to the pre-cleaned state. "
"And so we're stuck with a mess that we're too afraid to clean. Our estimates grow with every passing year, our productivity continues its asymptotic plunge toward zero, and yet we're helpless to do anything about it, paralyzed by our fear
"Have you ever brought up some code on your screen that was ugly? And the first thought through your head was, 'Wow this is ugly, I should clean it'? And the next thought in your head was: 'I'm not touching it'. Because you know if you touch it, you'll break it, and if you break it, it will become yours"
"Sometimes the mess gets so bad, that we contemplate a dedicated effort to clean it... At first our employers might even support this idea. ... But cleaning code is hard and fraught with risk. When we clean a module, we have no way of knowing that that module still works properly. Perhaps we've introduced subtle bugs, or race conditions, or data corruptions. The more we clean, the riskier the situation becomes. The ad-hoc manual tests we've been running to make sure that the system behaves properly, begin to fail for reasons we can't easily explain. We start to debug and the debugging time grows, and as it grows, it eats into the time we thought we'd have for cleaning. After weeks of cleaning and debugging, we finally run out of time, and although we've done a lot less cleaning than we wanted to, and a lot more debugging than we'd hoped, we think the system is at least a little bit cleaner. So we hand the new "cleaned system" to QA... And unfortunately they return with a huge pile of defects. These defects are daunting, they contain inexplicable behaviors, data corruptions, even crashes. The list of new defects is so long and so puzzling, we don't even know how to estimate
how long it would take to repair it. After much wailing and nashing of teeth, we finally conclude that the only sane action is to set the "clean system" aside, and to revert to the pre-cleaned state. "
"And so we're stuck with a mess that we're too afraid to clean. Our estimates grow with every passing year, our productivity continues its asymptotic plunge toward zero, and yet we're helpless to do anything about it, paralyzed by our fear
Friday, March 9, 2012
Give praise to your fellow programmers
I have been working on top of a code base set up by another guy. As I went thru the code, again and again, I got the feeling that it was well written and well designed, unlike so much other crap I see out there. It gave me "trust" that the code was doing what it was supposed to for the most part, and that the design decisions were sound, as well as an easy way to extend the code base.
In an act of kindness I decided to send an email to the original coder thanking him for good design, specifically outlining what I thought was good, so he knows I mean business. Pretty gay, you might say. Well gay or not, I think the guy needed to hear it, and he was very greatful for the praise.
I also realized that in my many years of coding, I only heard direct praise about some particular thing I did in the code only once or twice.
This just got me thinking how in the programming world it's so rare that we praise other people's code, and that's pretty sad. On the other hand, we do waaay too much bashing of other people's designs and coding abilities, behind their backs, or worse yet, in their face. Nothing wrong with constructive criticism, except it tends to be unconstructive for the most part. So there's some kind of mucho culture in existence that prevents us from giving each other props on a job well done.
Next time I work on a code base where I realize the guy put in some effort to make it easy for the next person, I'll make sure to mention it to them. You should do the same.
In an act of kindness I decided to send an email to the original coder thanking him for good design, specifically outlining what I thought was good, so he knows I mean business. Pretty gay, you might say. Well gay or not, I think the guy needed to hear it, and he was very greatful for the praise.
I also realized that in my many years of coding, I only heard direct praise about some particular thing I did in the code only once or twice.
This just got me thinking how in the programming world it's so rare that we praise other people's code, and that's pretty sad. On the other hand, we do waaay too much bashing of other people's designs and coding abilities, behind their backs, or worse yet, in their face. Nothing wrong with constructive criticism, except it tends to be unconstructive for the most part. So there's some kind of mucho culture in existence that prevents us from giving each other props on a job well done.
Next time I work on a code base where I realize the guy put in some effort to make it easy for the next person, I'll make sure to mention it to them. You should do the same.
Friday, January 13, 2012
The Mythical Man-Month quote
In many creative activities the medium of execution is intractable. Lumber splits; paints smear; electrical circuits ring. These physical limitations of the medium constrain the ideas that may be expressed, and they also create unexpected difficulties in the implementation...
Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified. [The Mythical Man-Month, by Frederick P. Brooks, Jr, page 15]
Subscribe to:
Posts (Atom)