Don't have to Pee in the Boat!
This comes up so often (guilty of it meself) that I have to write about it.
Programmers often come up with a scheme of logic in how they are going to implement their particular business scenario. Sometimes it is elegant, sometimes it's complicated. But more often than not, it isn't always completely "thought through".
Consider:
Two Irishmen are fishing on a lake. One pulls in a bottle, and as he unhooks it from the line, a genie pops out and offers him one wish.
"Turn the lake into beer", the fisherman says.
Genie waves his hand and -- "Poof" -- the whole lake turns into sparkling Harps!
Fisherman turns to his buddy and says, "Well, what do you think?"
His buddy says, "You jerk! Now we'll have to pee in the boat!"
Do you find yourself often having boxed yourself in, without a clear path to the Mens (or Ladies) room, and no key? And you have to "Pee in the Boat", e.g. you have to work around all the code you have already written, just to get something done that you perhaps didn't think about in advance.
I don't believe in anything that sounds like "Extreme Programming" or says you are supposed to "Smell the Code"-- for this very reason. I'd rather have everybody get together, map everything out, discuss all the logic beforehand (especially you want to do this when there is more than one programmer involved, because you can end up "Peeing in the Boat" just by yourself!). Now! --Once there's a plan, a contract, a schema, and some logic, the likelihood of getting your collective self "boxed in" and having to "Pee in the Boat" goes way down!
Nothing like a Harps after a heavy programming session -- along with a comfy place to pee! After all, we wouldn't want to spoil the lake, now, would we?
Programmers often come up with a scheme of logic in how they are going to implement their particular business scenario. Sometimes it is elegant, sometimes it's complicated. But more often than not, it isn't always completely "thought through".
Consider:
Two Irishmen are fishing on a lake. One pulls in a bottle, and as he unhooks it from the line, a genie pops out and offers him one wish.
"Turn the lake into beer", the fisherman says.
Genie waves his hand and -- "Poof" -- the whole lake turns into sparkling Harps!
Fisherman turns to his buddy and says, "Well, what do you think?"
His buddy says, "You jerk! Now we'll have to pee in the boat!"
Do you find yourself often having boxed yourself in, without a clear path to the Mens (or Ladies) room, and no key? And you have to "Pee in the Boat", e.g. you have to work around all the code you have already written, just to get something done that you perhaps didn't think about in advance.
I don't believe in anything that sounds like "Extreme Programming" or says you are supposed to "Smell the Code"-- for this very reason. I'd rather have everybody get together, map everything out, discuss all the logic beforehand (especially you want to do this when there is more than one programmer involved, because you can end up "Peeing in the Boat" just by yourself!). Now! --Once there's a plan, a contract, a schema, and some logic, the likelihood of getting your collective self "boxed in" and having to "Pee in the Boat" goes way down!
Nothing like a Harps after a heavy programming session -- along with a comfy place to pee! After all, we wouldn't want to spoil the lake, now, would we?
I've got to disagree with your conclusion.
ReplyDeleteI'm not sure what your concept of extreme programming is, considering you put it in quotes, but the more general Agile methodologies, such as TDD, if properly done, will have your code either already ready for an unexpcted change, or very easy to modify for it. That's what Agile is all about, unexpected change.
It is usually the planning ahead that gets you stuck, because you can never predict everything. I'm not saying not to plan anything in advance, on the contrary, working with Agile you will probably do more planning, but it will be short term, versus long term planning.
To give a more practical example, if the long term planning uses SQL as your database, then it's likely that you'll end up with either only that database supported on a seperate layer, or have it embedded in the actual code. Agile, on the other hand, would have forced you to not touch any database at all during the unit testing, and thereby forcing you to work against an interface, allowing you to create an implementation of that interface, and use any database that you'd want.
Your comment is appreciated. That's the problem - "Extreme Programming" or "XP" whether it is in quotes or not - means different things to different folks.
ReplyDeleteWhat I was referring to, more specifically, is any methodology that doesn't rely on some degree of formal planning and specification production.
ah, well, in that case, if someone's doing ad-hoc programming and calling it XP, then he's just a charlatan.
ReplyDeletePerhaps, but I think we are getting off-topic. This piece isn't about whether you are using XP or one of the agile methodologies, or whether they are better or worse than other methdologies.
ReplyDeleteWhat its's about is programmers writing code in such a way that they have "boxed themselves into" an untenable or difficult position due to lack of planning about the overall architecture of their application and how the different pieces talk to each other.
Although "planning about the overall architecture of their
ReplyDeleteapplication and how the different pieces talk to each other" is indeed a good idea, I think we need to be careful not to oversimplify the problem.
Even a well planned application will eventually run into issues where architecture and/or code boxes you. This is mostly due to the fact that requirements change over time and (even with good planning) there is no way you can guarantee that what looks good today in paper will be appropriated
with the new requirements. You can foresee some changes to the requirements and plan for them but the are others that cannot be foresaw (e.g. you company buys another company and now you need to update the system to account for a whole new set of requirements/technologies)
This is absolutely true!
ReplyDeleteHowever, I wasn't even getting this far -- really what I was referring to was in the initial development process which results in a first release of an application! Even a single developer can "box themselves in" usually via not having taken the time to think through before starting to write code. More than one developer, without proper plannning before and communication during the development process, even more so.