Here’s an interesting quote from Kent Beck. He says:
The product of software development is two-fold:
• The behavior of the system
• The options for extending and modifying that behavior in the future.
That second point summarizes what good software design is about. Each feature we build in our code gets us closer to release. But the way we build each feature can set us on different paths. If we don’t care how it works, as long as it works, then our launch may come and go without a problem. But when it’s time to return to that feature and make a change or an improvement, we’ll likely find ourselves wading through a tangle of spaghetti.
We want to take the other path, where each coding decision carries a question with it: What will I think of this code when I need to change it in six months? Will I understand it? Will changing this break other things, or will the change be isolated? This habit, to the extent that we can keep it up, allows us to keep improving our apps instead of getting stuck in spaghetti.
Paul Carney
on 09 Nov 10Time constraints will at times force you into a path where your code is not as efficient as you desire. We have also seen that we don’t have all of the information up-front, like how the people will use the feature.
Given that, we hold strong to an additional rule: you must not be afraid to refactor when it is needed. It is much more efficient to break apart the code and reassemble it earlier than later. I have never been afraid to do this, but so many people are.
Paul
Allan Ebdrup
on 09 Nov 10That’s why i love working on my spare time project Obsurvey. I can spend all the time I want on refactoring, there are no deadlines. Working under those conditions, refactoring is actually fun :-). And I’ve even managed to take some of the lessons learned from working on a large JavaScript codebase, and transferred them to my day-time job.
John Roescher
on 09 Nov 10I was actually trying to make this point exactly to a new member of our development team.
This mentality is especially important when designing databases.
JT
on 09 Nov 10As someone who builds and maintains APIs for apps on many platforms this rings so true.
Joe
on 09 Nov 10Spot on.
@Paul: Same here, and it’s great advice. Especially since you do indeed need to produce under those constraints.
If refactoring doesn’t change the behavior and it improves maintainability, it should be done. Automated testing should catch what you break, lowering the risk. If it does introduce a new bug, then you get more test cases this way, ultimately strengthening the system and further lowering the risk for the next refactor down the line.
Chad Burt
on 09 Nov 10Beck goes on:
This is one of the challenges I find most interesting when programming. I often find myself coding for too much future flexibility. It’s important not to err to far on one side or the other.
Kent Beck
on 09 Nov 10Ryan,
Thanks for the mention. That question of how much options value to add and when to add it is indeed the romance in software development. Answering effectively requires making decisions with insufficient information, both as to the need for a given bit of flexibility and sometimes even how to provide it. A wide range of strategies seem to work. Are there some that are clearly better, at least is a specific context?
Ryan
on 10 Nov 10Eric Evans drew the analogy to creases in a leather jacket. There are some parts of the code that should bend easily and others where it doesn’t matter. It seems like much of the art is in the ability to see where those joints are. Which parts of the software are worth isolating from other parts. I don’t have an answer in terms of strategy. Kent, you have so much more experience to draw from.
A cool thing about Evans’ take on it is he seems to suggest that finding the joints is a question of distilling knowledge from the problem domain. So it could be less about choosing between different implementations and more about faithfully representing things that matter to us in the domain.
Allan Ebdrup
on 10 Nov 10I’ve been thinking a bit more about this. And I think there might be an emotional side to this as well. When a developer is taken seriously and given time to refactor when he/she tells management that there is a need for some heavy refactoring, she/he maintains a certain pride in the code he/she is maintaining. On the other hand, if a developers requests for time to refactor are continually ignored and management demands that time is only spend on new features, the emotional attachment to the code diminishes, and the end result is a programmer that is maintaining code that he/she basically thinks the code needs to be rewritten from scratch, so he/she does not care about refactoring, at least not as much. That’s a recipe for disaster.
BTW: It’s impossible to post a comment here using chrome over https…
Blain Smith
on 10 Nov 10@Chad Burt: I couldn’t agree with you more. I run into that problem every day.
- “Do I use this set of variables?” - “Do I call my object XYZ or ABC?”
However, I feel confident enough that when I get to that point I feel comfortable enough to release it without any more though, because at least I have actually thought about it.
If I was to just blow through coding without thinking of any consequences then I would be kicking myself later when I went back in for a new feature.
So the tip I give to everyone is think about your implementation enough just before you go insane. You will have well though out code for production, yet it will be flexible for new features.
Daniel
on 10 Nov 10Of course I completely agree with the quote, and I’ve always taken it as pretty self-evident that you should design for easy modification whereever possible and feasible.
However, I can’t help being snarky and linking to this: Getting Real: It’s a problem, when it’s a problem.
I know, I know. You’re not advocating sloppy work in “Getting Real” or that people should actively make future modifications harder. But if this were a court of law, a lawyer would have a field day using your own words against you. Like last week’s post of lessons from the teams system, where you advocated a more in-person interaction than previously.
Again, I’m not saying you’re a bunch of liars or anything, and I always took Getting Real with a grain of salt (so to speak), but I still find it a little chuckle-worthy how your insights… “evolve”. Especially given Getting Real’s very direct, tough-talk tone.
Ryan
on 10 Nov 10“It’s a problem, when it’s a problem” remains a big part of our process, and it fits together with this post. The missing factor is that everything doesn’t need to be optimized for change. If you can hypothetically imagine a problem, but the need isn’t completely convincing or pressing, then there’s no reason to factor out that duplication immediately. Compare this to the dogmatic view that “duplication is bad, it makes change hard, therefore we must never ever have duplication.” The statement from Getting Real is a counterbalance to the tendency to refactor everything to death.
Rob
on 10 Nov 10Hi Ryan, I am in the same boat you were in years ago. I am a web developer now but want to move towards software development. What platform or language would you say I should focus on? I currently prefer C#, ASP.NET and MS SQL Server. My goal is to develop apps for various channels i.e. desktop, web, iPhone, iPad, android. Thanks.
Daniel
on 10 Nov 10@Ryan: Of course, and I’m a big fan of Getting Real (and of that chapter in particular, as it’s been good to throw at a boss/colleague or two when things got bogged down). I just couldn’t resist a little jab.
But I do think there’s a somewhat interesting point about writing in there. You guys favor brevity (I agree and I’m trying!) and pretty direct talk. But that just makes it easier to take potshots at, if you later write something that seems to be the opposite (when taken literally with no contextualization). I know Jason F wants people- especially students – to write more concisely, but there’s all the context and little defenses people – students in particular – pretty much need to write, just to avoid it being nitpicked apart. Like I just did with your stuff (albeit in jest). This argument is a recursive example: You can say “write less” and people might say “but what about…”, or you can say “write less, except if it’s to…”. The latter isn’t concise but it’s more precise.
Too many different but categorical statements on complex topics and you get the Bible, which can defend and negate all viewpoints simultaneously.
Or you could just not care about nitpicking critics. Fine for you (and I agree) but not on a term paper. Unless Jason does start teaching, of course.
This discussion is closed.