quick-and-dirty vs. good design

Question

What do you do when your manager wants you to implement something in a quick and dirty way and you just know it's going to backfire?

My manager wants me to develop a web app for a client and to do it as quickly as possible. This is the first web app we're building for this client, and I think it's important that we do it right so that we will be able to build upon it when they inevitably ask us to enhance it or create a new one.

I'd like to spend some time setting up a framework (even if it's just something simple like Stripes), and configuring tomcat to use DBCP. I also think we should be using css templates, and giving at least a minimum amount of thought to the presentation and design of the app as, in my opinion, nothing looks quite as unprofessional as a poorly designed web page (unless it's an email with really bad grammar).

The problem is not so much that we're under pressure to get this done, but more that my manager does not feel he can justify billing extra hours for something he himself does not consider a necessity. His "just get it done ASAP" approach has already backfired a few times - once, for example, he told me not to design the code to handle a certain error situation as it was very unlikely to occur, and then when it did occur it was a big mess (that I had to clean up).

So what do I do? Do I really do it "quick and dirty"? Do I decide that the quickest way is to do it right and deal with the fallout if it takes me longer than he had hoped? Part of the issue here is that while I have done web development in the past, it's always been within an existing framework, so setting up a framework from scratch involves a learning curve for me.

Answer 1

Ruby on Rails. If that's an option. I've heard plenty of times that it's the fastest way to get a CRUD site up and running well.

[edit]

Building your own framework is a huge waste of time, you're not going to be able to build a world class framework in any reasonable amount of time. Don't reinvent the wheel. I've heard plenty of programmers say "oh yeah I could build that soooo much better." Sure but could you build it even close to as good in the 5-10 hours of paid time that it will cost your company to just buy it outright? Unlikely.

If this is something that your company does frequently then you should talk your boss into letting you find an off-the-shelf solution to the "quick and dirty but still decent" problem. It might mean extra time now but will save time in the future.

[/edit]

Answer 2

Keep in mind that in his point of view, if billing lots of hours means less work in the future, it could be a good marketing approach (even if it's a horrible design decision) to write it quick and dirty now so the client likes it, and when they want changes he can bill more hours in the future because now he has the client "in his net".

But my advice is: look around you, he's in charge, so do it his way otherwise you're only creating problems for yourself. If you want to do things right, become the boss or find another company that does believe in doing things the right way. But simply going against the grain will only get you fired or in the doghouse with this guy, this is how life works.

Answer 3

This is a case where you need to manage up. Your boss doesn't see the need to implement a good design because he doesn't see that it's going to be easier in the long run. You can either convince him now or make sure that he sees the problem when modifications end up taking longer. At the very least you can steer his thinking over several small tasks so that you train him to go for good design over time.

Answer 4

Just do the quick-and-dirty implementation. Your job is to turn the spec into a working program, not to analyse tradeoffs between immediate costs & future benefits. I've worked with engineers who insisted on adding loads of layers of indirection, wrappers, unused code etc. which no-one was paying for, insisting they knew better than the PM. I've also been that guy (for a couple of years after I graduated) and it does not make you popular. I don't do it anymore.

Answer 5

Hmm, if your boss is only willing to fund quick-and-dirty and you disagree with the assignment, then find another job. Sounds like you don't like doing what you are being paid to do.

Answer 6

I'd go quick & dirty if that's what you've been asked for, as jcollum suggest, Ruby on Rails mught be a solution.

The reason I'd go for quick a dirty, is that if the user and your manager have a time frame and budget, and you can provide a stable solution that meets these and any other requirements, you should do so. Bottom line, if you're working for someone else, it is about meeting their requirements, not necessarily your own ideas about best practice or framework design. That said, if you can convince your manager and the client of the long term benefits of more upfront investment for a better long term outcome, go for it, and fair play to you.

My guess is once you have done a few more implementations, you will be better able to combine fast & good.

Answer 7

On the one hand you're not necessarily privy to all of the factors and pressures on the boss. Perhaps he/she knows this is a "one-off" and you won't be doing any business with this client.

The bottom line is that you're getting paid to implement whatever they tell you to implement. Yes, you have a responsibility to point out the pros and cons but, in the end, it's their decision.

But, to be safe, document EVERYTHING! If people start playing the blame game you can at least have your backside covered. (Might not do any good but always protect yourself.)

Answer 8

My advice would be to say that there is a quick and dirty way to meet the requirements within X days/weeks/months and that if there are major enhancements or features then there will be a cost to move to something larger that can handle what is now required.

Something to consider here is the idea of YAGNI if the client doesn't want anything more than the basics that they wanted in the first implementation. There is also the question of how much of a framework will you be building in this first go round.

Answer 9

If you were in charge, I would imagine you'd do it the "correct" way with a good design, even if it takes longer. The problem though is your manager is in charge. So, this sounds like a conversation you should be having with your manager.

Remind him (subtly) of the times his approach resulted in a mess and suggest that a bit more attention be made to the project. Suggest it may be a good marketing decision to put a little more effort into this project because the relationship with this client may be crucial. Don't get into an argument, just make yourself heard. At least it may get him to stop and think again about his decision - maybe he can have another conversation with the client about how much they're willing to pay.

In the end, respect his decision but make sure he does realize it was his decision and you're simply following orders. That way if a problem does develop in the future, it doesn't end up being your problem.

If he's not the approachable type, I think you're stuck doing it the quick-and-dirty way. I would document the situation though to minimize future ass-biting potential.

Answer 10

If by 'first web application' you mean prototype then you should probably do it quick and dirty. Your client probably wants to see something before they commit to anything. You CAN do something quick however; without making it dirty. If you were careful about how you designed the web app and wrote it you could probably turn the web app into a work of art in no time after you've released the first version.

Answer 11

Start polishing up the resume.

Answer 12

Do quick and dirty. That's what they want, that's what they're willing to pay for. Take the money and deliver that.

Later, when the system is unmanageable because it's complete and utter chaos in there, and the client is in a position to want and pay for a robust, well-engineered solution, take the money and deliver that.

See, you get paid twice!

Furthermore, a crap solution will end up with some ongoing manual processes. These can be charged for. You get paid again!

No wonder your manager likes that approach!

Answer 13

I feel that sometimes you have to make choices based on integrity and not fold to the demands of expediency or just because your under pressure from your boss. That doesn't mean I have an answer to your question, only you have to decide for yourself what is appropriate in this situation, with this customer, in your organization. Ask yourself:

• How much does your boss really know about what the customer wants?
• Do you know better than your boss? Is your relationship with the customer stronger?
• Where is the pressure coming from to do it quickly?
• Does the customer realize the costs/benefits associated with "quick and dirty"?
• What kind of orginization do you work in? Would you consider yourself kind of more of a consultant (very close to the customer) than an employee or vice versa?
• How well thought of is your boss (at your company or by the customer? Similarly how well thought of are you?
• Is the code truly throw away or if its going to actually be used in the future

Answer 14

I wouldn't be too judgemental on the boss. Like many people say, he/she has a POV just as you do. You need to adapt to handling this type of demand by learning some kind of rapid prototyping tool. I use the Microsoft platform for business and web applications (Java for scientific tools) so whenever someone wants to see a prototype web site I can hack something together on my local dev platform pretty quickly using ASP.NET. Usually for a prototype, ugly doesn't matter as much as functionality. If the customer knows a thing is possible then they will be apt to buy into the beautification (unless its internal - then who cares what it looks like - ha!).

Answer 15

In spite of the risks, I'll offer a management perspective on this. :-)

One challenge I've had with some team members is that they sometimes have a hard time seeing the big picture. That's obviously a statement that developers can make about their managers too--certainly managers (especially nontechnical managers) can fail to appreciate how hasty decisions now will lead to problems later. But I'll repeat that it's not just managers who can miss the big picture. Developers can too.

One time my team was supposed to develop a simple demo, and I had two people working on it. This was in all likelihood a throwaway demo. Was there some chance that we might end up keeping it and elaborating it? Sure. The chance was even decent--maybe (just making up a number here) 25% just for argument's sake. After nearly a month there was no deliverable and finally I called BS. It turned out that the developers were "engineering" the thing. Setting it up to be modular, pluggable, testable, etc. I told them to stop and I wrote the demo myself in a single afternoon. The "big picture" was to deliver a proof of concept to the customer quickly, and if for whatever reason we decided that we wanted the demo to evolve into an actual piece of production software--fine--in the worst case we throw away a single afternoon's worth of "hard work". And that was the worst case. It wasn't like I was able to make a few hundred lines of code that complicated.

No doubt sometimes managers make bad calls in the name of expediency, but just because I ask my team to do something quick-and-dirty doesn't mean I'm being short-sighted. Most of the time it means that delivering value quickly is more important in the situation that getting the engineering right. Unfortunately for some developers (a minority, to be sure), the very suggestion is blasphemy.

Answer 16

Think about the fact that you are supposed to be a "professional software developer". Being a member of a professional group means adherring to some codes and rules. That means that you don't just give up on your principles just because management tells you to.

If you really believe that setting up a framework and using CSS templates is necessary to deliver a product of proper quality, then insist on doing it.

Imagine if a construction engineer was told to do a bridge design in a quick-and-dirty way by his manager. Would he do it even if he knew the design was of poor quality? What would be the consequences if he did, for him personally and for construction engineering as a profession?

I think we as software engineers need to take more pride in our work, and show more professional responsibility.

Answer 17

I'd interpret "Q&D" to "Quick and Feature-Poor". Dirty is seldom Quick, even for a demo or proof of concept. Whatever you do to start, you'll be refactoring it anyway. Just give it the time available, and focus on YAGNI and Minimum Sufficient Solution.

Answer 18

If it's just a demo for a client I think a quick-and-dirty solution is sufficient, but ultimately it is you're job as a developer to protest if you think it's going to backfire. Uncle Bob in Clean Code drives home the point well:

"What if you were a doctor and had a patient who demanded that you stopped all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss, and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of the disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.

So too it is unprofessional for programmers to bend to the will of managers who don't understand the risks of making messes."

Answer 19

Allow your boss to learn from their mistakes.

If you always strive to protect them from themselves then they will never be able learn from their bad decisions, and you will always be trying to mitigate their next bad decision.

It is also important that you don't shield them from the repercussions of a bad decision, for example by quietly putting in a weekend for something that you feel guilty for.

You can and should of course do all this graciously with no hint of spite. Better still, diplomatically talking through the reasons for each approach as early as possible can work wonders.

Of course some people never learn ;-)