How many times have you seen this:
A new software project starts, and a lot of design is done up front so
the actual code and organization of the project is fairly clean. As time
goes on and requirements change, the project mostly stays clean. Then
someone will be working all on their own and think, “Hey, I’ve got this
job I’m trying to do that doesn’t really fit the way the current design
and architecture is, so I’ll just jam this little helper/object/whatever
right over… here… yeah. There we go.”
A little time goes by and someone else gets a similar requirement,
can’t find the little helper/object/whatever that the other developer
put in (because it isn’t where you’d expect it to be), so re-invents it
and jams it somewhere else.
After not too long, you step back from the project and it’s not so
clean anymore and no one can figure out why.
Jeff Atwood wrote about this a little while
ago. The concept
of “working clean” in code. I think there are three problems to overcome
when trying to maintain a clean project.
First, education. I’m finding that not too many people in software
development actually have a formal computer science education. Not that
that’s a requirement to be a developer by any means, but even if you’re
not writing compilers for a living, understanding why you might not just
put every single method or property you might ever need in the base
class of your object model is handy. That sort of education - or maybe
it’s intuition? - is sorely lacking in a lot of developers.
Second, communication. People don’t communicate what they’re doing, or
they assume everyone knows what they’re doing already. A task called
“Create Data Provider” doesn’t necessarily imply to the team that you’re
going to be modifying the UI classes so folks aren’t going to expect
things to change there. If people were to do a little bit of design up
front and say “here’s all the stuff that has to change,” it’d be easier
for the rest of the team to add input and correct design decisions prior
to a lot of work being done. (Admission: this is probably more of an
issue on a smaller team with a less formal process.)
Third, work ethic. I find that many times people just don’t care. “Oh,
yeah, I guess I did sort of hack that in there without any thought to
how it fits in the big picture. We’ll fix it later.” But you know you’ll
never get to it later - there’s no time! They know at the time they’re
doing it that it’s the wrong choice, but they just don’t seem to care.
I’m not really sure how to address that.
We need to quit designing by jamming, folks. Stop jamming code in
there. Take a second, breathe a little, and step back - look at what
you’re actually doing and do it the right way.
(I know I’m going to get a lot of folks with the “in the real world…”
sort of thoughts. If your company/process allows you to provide your own
task estimates, you need to factor the design into your task. Don’t say
it’s going to take you three hours when it’s a six hour project. On the
other hand, if you don’t get to provide your own estimates… well,
maybe you’ve got other issues to deal with.)