+972 52-548-6969
No Broken Windows
I had to deal with a change request today. The customer wanted to be able to manually enter /edit data into administration tables that are supposed to be handled using batch processes only. What he wanted was really simple, and could probably be handled using a grid + edit + paging in half an hour to an hour.
I refused to build it that way. The customer is probably the best I have had so far, but no one access my database but my application. That includes the admin module as well. The reasoning is a little more than extreme reluctance about the database structure, it is also a deep aversion of having a foreign body in my application. All the application works in a certain way, I am not willing to change that, even for such a "simple" request.
So I spent a few hours today and built an interface that match the rest of the application, that is usable and pleasant to the eye, that is actually thinking about the user . It took about four hours vs the 1/2 - 1 hours that the simple approach would take. The complete version required stuff like: resource files, two level validation, transactions, DB constraints, MVC, etc. The end result, however, is something that I am proud of, something that would not taint the application with "just a quick hack" mentality.
This is an application that I am proud of, and I refuse to not be proud of any and all parts that are under my control.
The mentality here is that the second that you allow a "quick hack" into the application, it spreads. I have seen it happen in projects were toward the end of the project it started to sprout all sorts of "interesting" ways to solve a problem because "it is simply this or that", which has led to total and complete chaos down the road.
Do not allow broken windows in your application.
Comments
Note To Self: Don't have Oren fix your car :).
You're not going to believe this (based on what's coming next) but I agree with 90% of what you're saying: don't build crap because your client tells you to.
However :) there needs to be some form of ego check here. To me it's dangerous to "put your foot down" as a matter of course- you may know better technically, but that doesn't mean you know everything.
This happened to me:
My client that I worked with at PayPal was pretty technical but didn't know as much as I did about .NET. It came time to user test (internal) the application I built for them and at the last minute he demanded that I change the way we "tagged" things, and laid out a series of requirements that crawled deeply into actually defining the data structure I needed to use. It wasn't simple, and his solution was very brittle indeed.
His reasoning? He didn't have the time to wait, nor the budget to pay me to "do it right" but the feature was requested by his boss and he had no choice - this is a fact and reality of what we do. He knew enough about Databases to be dangerous and so he directed me to do what he asked. And I did.
The user testing was a success, and we ended up leaving the application the way it was (with his structure) because it worked and it didn't fail. It wasn't elegant,was pretty brittle, and probably not easily maintainable, but it did what he needed it to and it's still in place, working just fine.
So, my client's happy, the application is done and live... if I would have put my foot down, neither would be the case.
How would you have handled this?
Cheers to that! I wish every programmer took that stance rather than the sheepish path of appeasement. Its our jobs to steward the technology in the proper direction for sustainability and business continuity.
The last place I worked that's all they ever wanted were quick hacks that were impossible to maintain. The users wanted direct access to the system for two reasons:
They did not by any means have their business process nailed down.
They wanted to break the business logic and fudge the numbers to make thing appear better than they were.
Broken windows.... I always enjoy how u apply the knowledge gathered everywhere. In this case, I think it's 'The Pragmatic Programmer'.
Rob,
That really depends on the requirements. I would probably try to give him that feature, in a maintainable way.
I don't mind extra features (even when they are totally crazy ones), I do mind ones that hurt the maintainability of the application.
And yes, there are scenarios that for various reasons require a less obvious and less maintainable solution, etc.
I am afraid that the answer is "depends" :-)
The agile term “technical debt” comes to mind when I hear about hacks such as this. I am have been toying around with the idea of using a comment token in the code and marking obvious hacks with the token "technical dept". I could then create a graph that would show my iteration velocity (gross) in relation to my technical debt and show the product owner that if we don't start fixing this debt her net gain is slowly going to creep into the red and the maintainability will go along with it.
It's good to see you push back - we don't ask carpenters to "just build a quick simple roof with paper, it would be faster". I know of no handyman with any reputation at all that compromise their profession.
No, the carpenter says "this is how I do it, it takes 4 hours and I use wood" . Period.
Customers tend to forget this is our trade.
If they don't like the cost, then perhaps they need to wake up as well.
I agree whole-heartedly with this post. I discussed something similar about refactoring here if anyone's interested:
http://www.tobinharris.com/2007/7/10/should-your-clients-pay-you-to-refactor
@Rob, I also find it makes sense to do the occasional hack to meet deadlines and make customers happy. Now that I'm trying my hardest to stand up to this kind of thing, for my own good, and that of the project, I'd recommend that next time somone pays you to modify the code base, make sure the first tasks is to fix that broken window.
I sent this post to a colleague, and agreed partly but pointed out that it's the client who's paying and in the end it's their system. I agreed, but with the caveat that it depends who's supporting the system. It might sound arrogant for Ayende to call it "my application," but that depends on whether the client will one day call him at 5:30 and say "things are all messed up with your system," and expect it to be fixed by morning.
If my client expects that kind of support, and they tell me to do bad things, things that would be tragic in terms of maintainability, I have three responsible choices:
1) stand firm until I get my way
2) tell them "don't count on me to support this system."
3) phone my wife and tell her "I'm about to give up a little more of my
family life"
Option 1 is hard, but it's the easiest of the three. Sadly, most of us
usually make the irresponsible choice -- we go along with the client
without making the call to our wife (or whoever).
Another way to put it is, sometimes we're hired guns. In that case, we should argue strenuously for what, in our view, is the best choice. Very often though we are expected to take the role of doctor. In that we need to be prepared to say "sorry, I'm not gonna refill your Demerol perscription" (or build your a roof of paper).
Interesting post. But I'm struggling with one aspect. Ayende stated the original plan was to maintain these tables through batch processes. At my place of work, that would mean SQL scripts ran by DBA's through Query Analyzer. Isn't that already a broken window in your application? And aren't the dirty maintenance screens just another manifestation of that broken window--just one that allows a user to update data in a consist way instead of relying on a DBA to do mainenance?
I agree with the Ayende's general point. But sometimes our applications are not as pure as we might think. If I understand the statement about batch processing correctly.
Troy,
Absolutely NOT.
What I mean was SP / SSIS jobs that handles this, certainly not some random DBA that has to manually run things.
Those processes are part of the application, as far as I am concerened.
Ayende,
So, if these SSIS packages and SP's are considered part of the application, would you consider them broken windows in their own right? Maybe they aren't the same as a dirty maintence screen that avoids any kind of business logic and validation. But after reading your posts on SSIS (great job btw), I would consider an application that depends on SSIS to have a broken window already built-in. (How is it unit tested for example?) Especially if the business logic and validation is duplicated in the SSIS package.
Not trying to point a finger here, we face the same issues in our shop, so just wondering what others think.
Troy,
You wouldn't get any argument about SSIS being a broken window from me.
I agree with that and would do things differently now.
No business logic / validation is duplicated in SSIS / SP.
There are data validation logic, though, and that one is not tested (except by QA), simply because of the cost of doing that.
Nevertheless, those were build by the team, so they would not be doing nasty stuff like putting 4 in the UserType column, which is a valid but dangerous value, just because they had no idea about the implications of that.
Direct access to my tables is resticted to my application.
Comment preview