WTF Pop Quiz, or How not to create a customizable website
-
Imagine that you have an ASP.NET website with let's say 50 files and assorted images/css/javascript. You are tasked with making the site customizable so it can be "branded" by other companies. Do you:
A) Create some kind of custom settings data store to contain the names of logos/css and then refactor the pages to read in this metadata
B) Make the contens of every page that can be re-used into a User Control and reference them between projects.
C) Copy all 50 files into a new website project and keep it alongside the original version of the site.
Take a guess which one a "senior" developer at my company did. Now we have to remember to fix bugs in at least two places and since the files are named the same often I'll make a change only to see it not work, and spend 20 minutes or so tracking it down only to realize that I changed the generic-ized page and not the actual page it should have gone on. Instead of taking the time to come up with a scalable solution this "developer" just did the fastest, dirtiest thing to crank out code, and company policy is that we are forbidden to refactor code as we come across it because it wastes time versus just doing the daily tasks assigned to us.
-
@ObiWayneKenobi said:
Take a guess which one a "senior" developer at my company did.
What you do with this man is you badly hurt his family (physically), and then you kill him.
-
@ObiWayneKenobi said:
I still don't understand why people don't just ignore policies like that. I did, and it worked out great. We went from total build hell (our build scripts where crap) to nice and clean builds with a single button press. Just because I had the guts to do something about it.and company policy is that we are forbidden to refactor code as we come across it because it wastes time versus just doing the daily tasks assigned to us.
Don't ask. Just do. Worst thing is, you might have to say "sorry"
-
No, worst thing is I would be fired for not working on the busywork thrown at me, and I cannot afford that chance right now. Main reason is that the manager and the senior developer (and the CIO) expressly forbid it, so it would cause unnecessary trouble. You should see some of this code.. it's a downright mess and nobody changes anything for fear of breaking something (I mean things like renaming a variable!), or taking a few minutes to refactor out a method that's being called in half a dozen places to a single place; they would rather just copy and paste it and deal with it later (i.e. never) to get their assigned task done as quickly as possible and move on to the next one.
-
I would answer "C" as it is the best example of code re-use.
-
D) Use different web server instances (or virtualhosts) to serve different static content. If you can't do this easily, this app is TRWTF.
-
@zelmak said:
I would answer "C" as it is the best example of code re-use.
I just got slightly terrified by the realization that this is, in fact, a correct literal interpretation of "re-use."
-
@ubersoldat said:
D) Use different web server instances (or virtualhosts) to serve different static content. If you can't do this easily, this app is TRWTF.
Oh the app is most certainly TRWTF. You have no idea. It's an insult to .NET, and I've seen Classic ASP and PHP better written.
-
@ObiWayneKenobi said:
No, worst thing is I would be fired for not working on the busywork thrown at me, and I cannot afford that chance right now.
If I were you, I'd want to be fired at the moment. If nothing else, it gets you out of the abusive relationship and you get a great story to tell at interviews.
-
"C" as a first step, then as "A" or "B" or some other mechanism is being worked on, there is the ability to do automated correlation tests. Once everything is converted and passed, the original gets deleted.
-
@ObiWayneKenobi said:
snip... and company policy is that we ar forbidden to refactor code as we come across it ... snip
This is something I actually agree with. On the otherhand it is a real WTF is these opportunities for code improvement (via refactoring) are not logged and placed on the backlog at a high enough priority that they actually get adressed.
"Drive by" coding almost always has unintended side-effects.
-
@too_many_usernames said:
@zelmak said:
I would answer "C" as it is the best example of code re-use.
I just got slightly terrified by the realization that this is, in fact, a correct literal interpretation of "re-use."
I have a coworker who completely buys into that literal interpretation. Every single one of his modules for our team's flagship product is copy-and-pasted from his "templates" of "design patterns". Fortunately, I rarely ever have to deal with them, and when I do, I usually have fun complaining about it. However, bugs are not uncommon. Fixing the simplest things (like his fatfingering of Unicode support) can take him weeks, because the fix has to be applied to everything. Frequently we have the need to expand a function common to all of the modules, such as add a single new field. The tremendous weight of such a change cripples our ability to evolve and improve his work.But hey, code reuse is Best Practices. And so is consistency and the principle of least surprise. And symmetry, too. Those are the ones he cites the most when defending his poor foresight. Oh well.
(Oh hey, I think I mentioned this guy [url=http://forums.thedailywtf.com/forums/p/21183/252319.aspx#252319]before[/url]...)
-
@ObiWayneKenobi said:
No, worst thing is I would be fired for not working on the busywork thrown at me, and I cannot afford that chance right now. Main reason is that the manager and the senior developer (and the CIO) expressly forbid it, so it would cause unnecessary trouble. You should see some of this code.. it's a downright mess and nobody changes anything for fear of breaking something (I mean things like renaming a variable!), or taking a few minutes to refactor out a method that's being called in half a dozen places to a single place; they would rather just copy and paste it and deal with it later (i.e. never) to get their assigned task done as quickly as possible and move on to the next one.
It's time to spruceup your resume. However for reference, never have a conversation about refactoring with your boss unless you know they are open to it. Too many managers focus on the short term costs. They really don't care about saving time down the road. These band-aid fixes are often a result of pressures placed on them. Don't take it personally, just move on.Just laugh and learn what not to do. That way you can think of how YOU would do it better, make it a recommendation. Even if its turned down its still an initiative YOU took and another employer might appreciate someone who thinks of ways to help improve efficiency.
-
Easy* remedy:
1) Pick a module that said coder is entierly responsible for. Let's call it Module Foo.
2) Find a small bug in that module. Something simple that said coder will not find on his own. It can be anything from a small rounding error, or an incorrect datetime format. DO NOT FIX THIS BUG!
3) Wait until there are at least 10 forks of this project
4) Contact Customer A, suggest a neat feature they can request in Module Foo.
5) Contact Customer B, and suggest a DIFFERENT feature they can request in Module Foo. This will cause a copy-pasta fork of the project.
6) Repeat until there are ten different deployed versions of Module Foo.
7) All at once, make sure each customer "discovers" the bug, and puts in an emergency priority request to have the bug fixed.
8) Enjoy as that coder is saddled with the responsibilty a "quick fix five minute", and taking orders of magnitude longer than it should take to fix and deploy it.
9) For additional fun, bring up this bug way back at the beginning, but use the word "refactor". Get shot down under the guise of "It isn't worth spending five minutes refactoring now to maybe ten minutes later. It isn't good business sense." Document it. Bring it up later.
* Warning, this is neither easy nor a remedy.
-
@Xyro said:
Fixing the simplest things … can take him weeks,
<SeriousAndConstructive> That sounds like a good opportunity for a CBA document.</SeriousAndConstructive>
If that programmer ever complains about their workload, jump on the complaint immediately with "stop complaining, you chose to do it that way, obviously you like the work!".
It pisses me off when people pick the easy way out and then complain later on as if they are the victims.Thankfully the only contact I have with such people is reading the stories here.
Keep the stories up! :-)
-
@Lorne Kates said:
Easy* remedy
He could also try to write the most unmaintainable, obfuscated code possible (while innocently being able to claim to just be following "leadership by example") until that whole pile of fertilizer comes crumbling down on them and they just have to clean up the mess they created...
-
If you're stuck with C) and it sounds like the copies are still largely similar: check them both into your VCS as branches. Then just remember to make "global" changes to the base branch and merge them into the other. It's a hell of a lot better than nothing.
That doesn't count as refactoring does it?
-
@ObiWayneKenobi said:
No, worst thing is I would be fired for not working on the busywork thrown at me, and I cannot afford that chance right now. Main reason is that the manager and the senior developer (and the CIO) expressly forbid it, so it would cause unnecessary trouble. You should see some of this code.. it's a downright mess and nobody changes anything for fear of breaking something (I mean things like renaming a variable!), or taking a few minutes to refactor out a method that's being called in half a dozen places to a single place; they would rather just copy and paste it and deal with it later (i.e. never) to get their assigned task done as quickly as possible and move on to the next one.
So instead of spending 20% extra time on each issue (still do the work that you're asked to do, just let it take a while longer so you can fix other things) you are working on making it worse.
If you spend enough issues taking 20% extra time to fix the code, then eventually your normal work will take less time. Now you are just introducing more bad code, making fixing it harder, and making each issue take longer. Until the company explodes because it cannot make a profit anymore. And then you're also without a job.
-
@ObiWayneKenobi said:
C) Copy all 50 files into a new website project and keep it alongside the original version of the site.
[...]
Now we have to remember to fix bugs in at least two places and since the files are named the same often I'll make a change only to see it not work
Or what happened at a former employer:
D) Botch a CVS merge so badly that you don't just end up with two separate code-bases, generic and customisable, but two code-bases in separate and no longer reconcilable branches...
I suppose at least that made it easier to know which of generic vs customisable you were actually working on.
-
@havokk said:
If that programmer ever complains about their workload, jump on the complaint immediately with "stop complaining, you chose to do it that way, obviously you like the work!".
FWIW, I've done that a few times, and have had more than one fight with him at work. It ain't pretty, and he fights dirty - mostly by ignoring me and subjecting me to long, rambly stories of his "experience". This one time he just totally lost his patience and just stormed off back to his cubical (which is directly in front of mine, so it wasn't much of a storming). Responding to coworkers in the manner you suggest may sometimes work, but I think it mostly doesn't, and the net effect is just more strife between you and your workplace adversary. And when that adversary is on your own team, it can make for some painfully awkward working relationships.Instead, at this point, I've adopted the posture of Not My Problem™, which I have the luxury of taking only because my recent projects haven't intersected his all too much. I think my boss may actually be doing that on purpose. He's a pretty cool boss, although he's not one whipping on his own subordinates even when they need it.
-
Oh lord... I went through this exact rigamarole with one of the websites at a previous employer. I literally begged them to let us set up a parameter-driven system along the lines of option A, even did a proof-of-concept and a writeup explaining the advantages vs option C. Hell, we were halfway there already, since I'd CSS'd the site. But in the end, they decided that C was faster, so now there are two sites being maintained--assuming they remember to.
Of course, this was all meant to be moot as we were supposed to be refactoring the ASP/ActiveX insecure butt-ugly monstrosity in the very near future. I left the company a year and a half ago. I just checked the site. Same old monstrosity.
-
@galgorah said:
However for reference, never have a conversation about refactoring with your boss unless you know they are open to it.
And make sure that in their personal lexicon "refactor" means "refactor", not "add new features".
-
I have to be honest in that it disgusts me how so many people equate refactoring with a dirty word, something that sucks up developer resources for no tangible value, when in fact refactoring provides the most value of anything as it ensures that you have a working application to add new features to and not a festering mess where even the simplest of changes takes days due to a rat's nest of dependencies.
-
@ObiWayneKenobi said:
I have to be honest in that it disgusts me how so many people equate refactoring with a dirty word, something that sucks up developer resources for no tangible value, when in fact refactoring provides the most value of anything as it ensures that you have a working application to add new features to and not a festering mess where even the simplest of changes takes days due to a rat's nest of dependencies.
That's the best case, but not necessarily the most common. The more messy everything is, the more likely that it's got layered on bug fixes and stuff, and it can be really difficult to get all of that correct in the refactoring. Obviously, if you have some automated tests that cover all of that, it makes life a lot easier. But what are the odds of that?
It's very possible that the distaste for refactoring is based on hard experience. While your life might be nicer with neater code, the process of getting there can be pretty awful from a business standpoint, and then once you've refixed all the stuff you broke, you're back to where you started. It's easy to see how the benefits might not exceed the costs.
