You know you're in trouble in hardly more than a glance. All the methods are long and busy, and do their work data members of other classes... other classes without any behavior. Methods are placed in ersatz global functions. Why? Because that's where they're closest to the runtime. Perhaps in module initialization, perhaps one function call away from the "static main."
The solution for the code is well known. Extract method, move method, pull up method, red/green/refactor.
The real problem here is that we don't know enough about prevention. Why do we keep getting saddled with busy methods running roughshod all over beany classes? Is it laziness, poor education, a lack of good examples, a confused sense of practicality? The human problem is interesting enough that I need insight from a wide range of agilists.
Deming laid the fault of this stuff squarely at the feet of management. Although I think there's probably better tools available for educating them than what we use today.
ReplyDeleteActually Deming blamed "the system", which being controlled by management is often essentially the same.
ReplyDeleteEven the best trained, most intelligent, most "willing" worker can never overcome the system within which he works. I didn't always believe that, but I do now.
The sad news is that many companies regard software as an afterthought. It is something to be outsourced to the lowest bidder unless someone internal can get it written for less. It may be that the software determines the ultimate success of the product, but if software itself isn't an essential part of the business model of the organization, you are gong to be in for a rough time trying to get cooperation on enforcing software design standards. Much less giving any thought to spending the time to let people try to develop any.
The sad thing is that most people, given a "manager title", will see themselves as the administrators and maintainers of the system as it exists. They get swallowed up in reports, managing appearances, and policing compliance.
ReplyDeleteThere are some who see management as role in which you help get things done, but many of those see it as a role where you *make* people do their work.
A few brave souls see management as the position where you help a team of people become as effective as possible.
Mind you, if "the system" were a great system, things would be different. Instead, we get a lot of lives dedicated to propping up an aging, delapidated building. That, and hoping that they aren't made irrelevant by some whippersnappers who don't have an aging ediface holding them back.
Yet, some programmers feel like it's the same kind of job, no? Prop up the aging ediface with if-statements and dirty hacks so it doesn't fall down just yet?
ReplyDeleteWhat percentage of programmers do you think are trying to gentrify the slums of old systems?
Also, I just reread the clean functions chapter of Clean Code, and was reminded of the ubiquity of beany classes and monster methods. I suggest that we point our friends to that book when we find them flagging in their zeal for code renewal.
ReplyDeleteOur code really should be getting better year by year.