When working on a product that needs to be done soon and work well, when is it OK to sacrifice maintainability and "neatness" of design in order to get the thing done and out the door quickly? And to what degree is it OK, especially when the techniques used to make it "neat" are new to me?
-
3Only when it's absolutely necessary.– FrustratedWithFormsDesignerJun 28, 2011 at 16:34
-
1It's pretty much the norm where I work. "You can pay may now, or you can pay me later" has never been so true.– MetalMikesterJun 28, 2011 at 17:28
-
Sounds like a looming deadline...– user1249Jun 28, 2011 at 17:30
-
1I'll take the contrarian view and say always. If a project is not done, no one cares if it's neat.– drxzclJun 28, 2011 at 19:44
-
1@MrJ, I was actually thinking about the users.– drxzclJun 28, 2011 at 22:11
9 Answers
Remember that you are employed in order to support a business. In some way, your software is affecting the bottom line of the business. You need to strike a balance between a technically perfect solution, and the time to market of your product and how much benefit the business will derive from it.
In my experience developers often get hung up on worrying about technical perfection. But there are very valid reasons to sacrifice quality attributes such as maintainability or performance in order to get a product out the door quicker. It depends on the business and the product. But "always strive for a perfect design" is too simplistic an approach.
At the end of the day, the only thing that matters is value to the business. Figure out how to maximize it in the short and long term and aim for that target.
-
3I agree with the spirit of your answer, but you're missing some details.
You need to strike a balance between a technically perfect solution, and the time to market of your product
I'd disagree, that is beyond the responsibility of a developer. They absolutely must remain aware of it, but they should give the information to someone responsible to make a business decision. Jun 28, 2011 at 17:02 -
2Look at Blizzard for example. They have huge success with their games and do not really care about time to market, as they think that superior quality will eventually pay off. And it does, although probably not for all kinds of software.– FalconJun 28, 2011 at 17:07
-
1I absolutely agreed with @StuperUser and @Peter Rowell. Oftentimes it is the responsibility of the developer to communicate the technical risks, problems with cutting corners, etc. to people higher up in the food chain that make the decision. If that is your role than you should focus on communicating that as accurately as possible. However, the more you understand what drives the value chain of the business, the better you will get at that communication. Jun 28, 2011 at 18:28
-
1@Falcon Blizzard may indeed sacrifice short term gain in early release for long term game in a solid, stable, enjoyable game. That is perhaps the appropriate balance for them. But it is not the appropriate balance in all cases. Jun 28, 2011 at 18:30
-
4The reality is that most new software products are going to fail in the marketplace, not due to quality issues, but because customers just don't want them. So, dedicating a lot of time/effort to creating a solid manitainable architecture in version 1 of the product may not be the best use of resources. The businesspeople who push to get something out the door aren't the idiots that many of you think they are; getting a product into customers' hands to determine viability is a very smart thing to do. Jun 28, 2011 at 19:37
The term "technical debt" is very handy to help inform business decisions like this. Any work you don't do now will cause some amount of work later. Just like with finances, taking on debt is risky but may be worth leveraging if you are going to be able to pay the debt back later.
Having said that, technical debt isn't a 1:1 ratio at payback time. Bugs are more expensive to fix after release, and the impact on future productivity when developing from a messy legacy system can be outrageous. You could be looking at spending double the time fixing your errors, or maybe 1,000 times as many man-hours and resources.
Your job in this decision is to understand the ramifications of the particular pieces of corner-cutting you are considering, and then communicate those ramifications to the people making the business decision. This particular estimation skill might take a lot of research and work on your part to develop well right now, but it will be invaluable during your career.
-
1
When it is accepted and the consequences are understood by the owner/client/user.
A plumber has to take out a garbage disposal for repair. I want to use the sink in the mean time, but he would have to bill me for the time and materials to put in temporary pipes using tape that could break. This is also going to delay taking the disposal back to the repair shop. If I accept the additional billing with the understanding that I risk a clog. It will take a day longer to get the disposal repaired and an even longer delay before he can put it back, that's acceptable.
You can be on time and budget now, but sacrifice/risk an even higher charge in the long-run. This can be difficult to get non-technical people to understand, but that's what sales staff are for.
A lot of people give up way to quickly when learning something new and just do it the way they always have done it. If this is a pattern not only will your code suffer but your own skills as a programmer will remain limited.
Still, at the end of the day the only successful software is the one that ships.
-
"Still, at the end of the day the only successful software is the one that ships." Until it crashes and burns a few years down the road because it wasn't architected properly. Short-sightedness in action. Jun 28, 2011 at 17:45
-
1
-
If you can't ship something that won't screw you longterm due to short-sighted management, you don't deserve to be in business in the first place! Jun 29, 2011 at 18:44
After the soft deadline passes. And even then it is a very low degree of "OK". After the hard deadline passes it is, of course, moot. Because that is the nature of hard deadlines.
Furthermore, this incurs technical debt. For every hour/day you spend cutting corners in the git-er-done mentality, it will cost you roughly twice as much time when next you have to touch this project. If you must then it's best to rush, ship, and then immediately start fixing all your duck tape. Coming back to a hack-eyed project years later is a nightmare. If you will never touch it ever again, so be it, no one will care. But the only time I've left a project lie forever is when I switched jobs.
Remember though, timing these things is the job of the project manager. If you are rushed to meet a deadline, it is the fault of the PM. Do it right, do it once, and do it calmly and correctly. Life is too short for anything else.
All the other answers posted here are good. I would like to add though that as a developer on the project, you are the steward (protector) of the design.
If you don't stand up for the proper technical solution then nobody else will I promise you. You should always argue for doing things the right way to your boss and the PM should always argue in favor of the deadline.
Hopefully if you are in a reasonable organization a compromise will be reached that helps meet deadlines and also not stray too far from the design at the same time.
With that being said, don't assume that if the PM's deadline isn't reached that the world will end and the project will fail. It is usually not that black and white and most of the time the PM's deadline is soft and has room for adjustment.
Almost every deadline I was ever under on a PM schedule was mostly artificial. They will defend it tooth and nail and pretend otherwise however because if the PM pushes the deadline then the PM LOOKS BAD!
Just because the PM looks bad doesn't mean the project has failed. If you understand this you will be surprised how much you can get a PM to bend.
Quote the client for the neat design. If that quote is unnacceptable to them, then go into the breakdown of what each component will cost (usually cost==development time). Let them take items off "a la carte" if they choose. Many will jump at shaving off time for "useless" things like testing and design. Explain the risks of this approach, but if they accept the risk, then proceed as directed. If I only have enough money for a clunker car, then I am going to buy a clunker car, even if I know it will probably break down in 8 months. Your client has the responsibility to weigh these risks out and accept the consequences.
The one thing that you do not want to do is tell let the client think they have a beautifully designed piece of software, when they only paid for (and received) an untested piece of junk. If something goes wrong (which it likely will), in the first scenario they will look bad, but in the second scenario you will look bad.
It's never okay, but sometimes you have to compromise for the sake of finishing a project. The sad reality is that most businesspeople are completely ignorant and are more than willing to sacrifice maintainability later for something right now. The trick is knowing how to strike a balance; maybe the project won't be as neat as it could be, but as long as it's not a pigpen it's a worthy compromise.
That entirely depends on the question "Will you or anyone else conceivably want to modify it later?" If yes, you should try to have a "neat" design, otherwise you risk having to throw everything out and start again 6 months later.
Of course, you can take neatness too far, but generally a bit of neatness will save you work later.
-
4There's no such thing as a product that doesn't require maintenance, no matter what the client tells you. Jun 28, 2011 at 16:49
-
@crazy-eddie Pretty much no. It was meant as a loaded question; I can't really think of many cases where you would answer "no" to that question. Even a quick'n'dirty script meant for only one thing and never to be used again, could conceivably be edited and refurbished later. Jun 29, 2011 at 8:56