"Quick 'n Dirty" vs. "Correct and Proper"? 887
A not-so Anonymous Coward enters this query: "I keep finding myself on projects where a quick and dirty solution will bring in money for the company, and a correct (ie, properly documented, well engineered, process followed, etc) solution will get us left in the dust. When the Q&D solution succeeds, I'm left trying to explain why it can't be the FINAL solution (to PHBs and Marketroids that were fully informed of the situation prior to any work getting done). Most recently, work I did in record time was used to help bring in several large contracts, and then I found myself in hot water for not having followed process et al. So, to Slashdot: is it better to do the quick thing and greatly increase the chance of $uccess now, or to do the correct thing and avoid pain later (assuming there is money to pay for the pain later)?"
One reason why we need to absolve money (Score:3, Interesting)
Do Both. (Score:2, Interesting)
Whats a process ? (Score:5, Interesting)
What I find funniest about our development process is that the people most adamant about putting things in place and documenting developement usually aren't having to do all the grunt work they are suggesting.
Example (Score:2, Interesting)
Now, hear me out, an don't mod me up as funny or down as a troll. :)
Microsoft often takes the quick-and-dirty way, and despite this, they've been successful, because, on the whole, their project is usable to end users. This should be what you strive for in business. If it works 95% of the time as a quick-and-dirty solution, then worry about fixing that 5% later when you have time. If the end users can get their work done without causing any potentially serious complications, why bother?
Of course, I also have to develop databases using FileMaker Pro. All I know is quick and dirty!
Get the sale (and prepare for doing things right) (Score:4, Interesting)
That said, quick and dirty is always more fun.
Re:Passion is the key - if you're passionate, rele (Score:3, Interesting)
Quick, Correct and Proper (Score:2, Interesting)
Do everything you can in (one of) the correct way(s), but as fast as you possibly can. Q&D solutions often reach up and bite you in the behind when you least expect them, resulting in wasted time trying to fix the "solution". Taking some amount of time (but not too much) to solve a problem is preferable if you ask me. But when you have people that don't have even the slightest inkling about what you are doing breathing down your necks... I can see where doing it dirty comes about.
Re:It's like sex... (Score:3, Interesting)
As another poster said there is no easy solution despite all the analogy you can come with. it is a case for case.
Re:Passion is the key - if you're passionate, rele (Score:4, Interesting)
Think about it--why does the Open Source model produce better code [reasoning.com]? Easy--if the developer isn't happy with the code, it doesn't go in. If the other developers aren't happy with one developer's code, s/he loses commit access. And, let's face it, if you're not happy with the code, it's probably not fit to be in the product.
So, in many ways, whether or not you're passionate about your code is a damn good way to judge whether or not you've completed code worthy of actually making it into a product. Customers and managers win when their developers have passion for the code they've written.
Jouster
Money.... It's really all about the money... (Score:3, Interesting)
You see, if marketing folk and PHBs aren't heeding your warnings about quick-and-dirty solutions, and are telling potential clients that the sun will always shine and everything your company touches turns gold, then it is their responsibilty to deliver on those promises, not yours.
See, this is where that paperwork everyone always whines about comes in handy. Get rid of the bull ("synergy","integration", and oter hot words), keep from overdocumenting the situation, and make those "little notes" availiable wherever you go. Just do the jobs you are given, know your role, and give your tormentors no choice but to live up to their roles.
As far as dirty-vs-clean.... Bah... You really don't need opinions on that now, do you? Just give yourself a bit of backbone, man.
Re:what's the root? (Score:3, Interesting)
The kind with jobs. [washingtonpost.com]
Re:No easy answer (Score:5, Interesting)
Re:Professional Software Tester's Opinion: (Score:3, Interesting)
But why didn't it work. (Score:3, Interesting)
What I do (Score:5, Interesting)
I make the effort to point out the pros and cons of spending more time - then let my customers decide what they want.
However, one thing that I do (for the quick jobs), is to send my customer a very short email (after agreeing on how the project will be done) summarizing our agreement to do a "quick as you can" project. Then, at the end of a project, I re-send the same email - remind them what they agreed to!
The same technique should work if you are an employee at a company.
Sometimes it is correct to do a "quick as you can project" - other times it is better to go for maximum quality. A quick project should produce correctly running code, but will be more difficult to maintain and modify in the future.
-Mark
Re:Personally (Score:3, Interesting)
Every day I'm more convinced that quick and dirty is better because it gets code written which means it can be tested and often that means finding some aspect of the way the business is *really* run that was previously unknown.
Of course, I work doing business programming. If I drop one order a month at $40 that's no big deal really. Customer service will call that person, work it out by hand. Total cost to us is usually about 1 hour of customer service time. If I have to go fix that rare case to save $40/month and it costs the company $5k's worth of my time, that's not money well spent. We can process 99.9+% of all orders without a hitch. If I were coding for heart monitors however I might have a different attitude or at least much higher tolerances (I'm thinking 1 in a billion at least).
Seek the Tao (Score:5, Interesting)
"There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, `What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.'"
Re:No easy answer (Score:5, Interesting)
If you run over some code and you figure it could be done simpler, even if it's not your code, do it simpler NOW. If you find something has been done in a quirky way, fix it NOW. The general rule is that the code has to be understood for the next let's say ten years. We have strict coding guidelines regarding method naming and variable naming. If names are not fully self-explanatory they are replaced immediately even if they're scattered through the whole application. If critical parts like persistence suffer from a bad architecture, it is fixed immediately no matter how much work the rewriting involves. Finally, this leads to very understandable code and once you've understood the general application architecture the code is very easy to read, very clean and mostly pretty correct. There are hardly any quick hacks, sometimes they are inevitable though, to circumvent bugs in the software environment for example.
If you're suffering from lay-offs and don't mind 170 days of rain per year, consider think-cell [think-cell.com] (I'm only a student employee myself, neither owner nor partner, so it's not advertisement, just advice).
Re:Do Both. (Score:2, Interesting)
Look at part of my RMF-COM,
if (filespec1[1]==':') drv=filespec1[0]; else drv=0;
if (!strrchr (filespec1, '\\'))
{
if (drv)
retv=prepare_for_rename (drv-64, &zero, filespec1 + 2, filespec2);
else
retv=prepare_for_rename (0, &zero, filespec1, filespec2);
} else {
file=strrchr (filespec1, '\\') + 1;
for (travel2=2*(drv!=0); (filespec1+travel2) != (file-1); travel2++)
path[travel2-(2 * (drv != 0))]=filespec1[travel2];
path[travel2-(2 * (drv != 0))]=0;
if (drv)
retv=prepare_for_rename (drv, path, file, filespec2);
else
retv=prepare_for_rename (0, path, file, filespec2);
}
Pretty ugly code. And I haven't changed it since I dropped it in there. I don't think a real programmer, or a commercial developer, would ever put code THAT ugly in there, because it's TEH SUX0R when you have to read it to fix bugs etc.,
Just imagine if I could code in ASM. That can get a might uglier. At least I don't mutate C into my own language with #ifdefs like Bourne did with the V7 shell.
-uso.
Re:Worse is Better (Score:3, Interesting)
And my answer to the "Quick 'n Dirty" or "Correct and Proper" qustion is to use some or all of the Extreme Programming practices. I had been using some of those XP techniques way before anyone decided to define what XP was (mostly from hands-on programming experience over the last 20 years) and have found it provides a great balance between a perfect design and something that "just works". Having something that works is way, way more important than having a perfect design.
For the most part, that's the software that runs everything right now. The software that works. It may not have a perfect design, but it works. XP helps mediate the "bad design" part of it.
Re:Professional Software Tester's Opinion: (Score:2, Interesting)
Quick and dirty solution:
$1000 to make
$100000 to support
$1000000 in profit (for getting there first)
or
Proper solution:
$10000 to make
$10000 to support
$10000 in profit ('cause someone else got there first)
The nice thing about "Quick and Dirty" is that it can get you there first... That is a fairly important factor.
In situations where Time to Market is crucial, it's often better to do "Quick and Dirty", then start from scratch and do "Correct and Proper" for version 2
Re:One reason why we need to absolve money (Score:1, Interesting)
Re:Always Document Approval (Score:3, Interesting)
It sounds like it isn't your decision to call either way. So make sure you provide all of the information, including what the negatives will be, for both methods, then let the people who're paid to decide, decide.
Sometimes, whether we like it or not, whether it suits our meticulous geek processes, staying in business and dealing with shit down the line is a better option than doing it right and going out of business. It's that old line: I can do it fast, cheap or well. Pick any two. In the business world, fast and cheap are going to sometimes win.
The point is, for all you may disagree, you're not paid to disagree. You're paid to do as your manager and more senior management tell you to do. Your job is simply to give them the best information you can to make their decisions.
It's a hard lesson to learn. It goes totally against every feeling of entitlement we have. It doesn't stop it being true though.
Now the important thing is to keep the emails where you notify them of the negative consequences. You're not paid to decide, but you're also not paid to be abused for their decisions. By keeping the emails, you can prove you gave them the information and it was their choice. Knowing you have that saved can also help make the smiling and nodding easier.
Finally, ask yourself... If you were in their position, if you knew you were buying problems in the long term but it was the only way to stay in business long enough, would you appreciate every person who's paid to obey your decisions questioning you on things you already know, don't like, but have to do anyway?
Re:Plan it right, do it close, think "Phase 2" (Score:2, Interesting)
Completely correct. An old saying is that you should plan to program it twice, because you will be reprogramming it, no matter how large the pile of documentation and hours of planning sessions. Spending multiples more time "doing it right" when it, with pretty much certainty, will be rewritten is just a waste of time and effort (the same premise holds for all of the composite components that make the application as well).
Not necessarily a dichotomy (Score:5, Interesting)
"Quick & Dirty" is not necessarily the opposite of doing things properly.
Faced with a choice between "quick and dirty" versus a long process that is not even ready to produce code until everything is known, there isn't a company in the world who won't go with quick and dirty.
The long elaborate process doesn't really work anyway. The world changes too quickly.
What you need is a methodology which emphasizes development in stages. XP (Extreme Programming) and Feature Driven Design (a variant of UML) are two examples.
The important thing is to identify your fundamental interfaces, make sure those are right. Document them. And then feel free to code each and every component as "quick and dirty" as you ever imagined.
If you did the first part right, you can replace components later, add new components, etc.
If you didn't document your interfaces well... you've just delayed the failure of the project through absurd amounts of overtime. You have zero chance of longterm success.
It isn't even necessary to always have a grand master plan. Well documented simple interfaces can frequently be extended in ways that weren't anticipated when they were first created. But you have to focus on the interfaces - that's what allows for evolution.
The most obvious example of this is the Internet itself. The OSI stack was trying to do things "thoroughly", IP just wanted to be "flexible". Flexible can be developed cheaply, and unlike either pedanticly thorough methodologies or complete anarchy, has a chance to build itself up one useful piece at a time.
Re:Example (Score:3, Interesting)
For example, DOS. People today laugh at DOS and the problems it caused Windows on i386 machines. Many would point to it as a quick and dirty solution. But those who do fail to understand that DOS (a CPM clone) was a correct an proper solution to a 8086 with 640K RAM, and that they quickly started working on a replacement for more powerful processors.
Some correct and proper solutions from Microsoft off the top of my head (though a few may be tainted by overhype and feature creep): all early MS compilers, OS/2 (originally a MS project), NT, COM, integrated browser, and much of
p.s. I am not a Microsoft fan, being a loyal NIX fanboy and FOSS advocate, but credit has to be given where it is due.
Re:One reason why we need to absolve money (Score:2, Interesting)
> been corrupt from the start...
Sheesh, murderer.
Political "Science" -- the only science that forces itself on unwilling test subjects.
What's wrong with good, old-fashioned, rights-protecting freedom?
Given all the murderous history of mankind, and how it all orients around a violation of that principle, what's wrong with just leaving other people the hell alone?
Re:Not necessarily a dichotomy (Score:4, Interesting)
Pick your battles (Score:3, Interesting)
Software development is about dealing with change. Requirements change. Technologies change. Business plans change. Development teams change. Sometimes when we try to do the right thing, plan everything out, document it, create clean interfaces instead of holes in the wall... what we're really doing is betting against change, and that's always a longshot.
The best way to design, IMHO, is to start with a few good quick hacks that solve the bulk of your problems. Then put it into production and let the feedback tell you what you need to do. What do the users like? Where is the redundant functionality that merits adding infrastructure? What parts of the system are most problematic? We never really understand what we develop until we've had to build on it for two or three generations.
So my advice is leave your hack in place. If you have to change it a month from now, and then a month after that, that's a good sign that it's something that's worth doing right. If not, then your hack was the right thing to do, after all.
If you want to insulate yourself against getting slammed in the face by that hack, the best investment of your time is to write some good test suites. This way, if you add something that breaks your hack, you know about it quickly.
Just my little contribution to the background noise
Re:No easy answer (Score:4, Interesting)
There's no better way to guarantee that your product will never congeal than to be constantly changing it. What happens when the quirky code you just changed 5 minutes ago had just finished a month of testing and debugging? Or when your architectural re-write has a chain-reaction further downstream?
One of the most important things that good software development companies do is to track their defects, figure out where they came from and develop a plan for fixing them (or not...)
In the Apollo space program, the astronauts had a listing of every known bug in the computer software and what they needed to do when that bug got hit. You may ask "If they knew where these bugs were, why didn't they fix them?" It's a good question and I believe that the answer boiled down to "Because then you'd be introducing a bunch of bugs that you didn't know about."
Remember the time-money-quality (pick any 2) triangle.
Re:No easy answer (Score:2, Interesting)
Re:No easy answer (Score:3, Interesting)
You don't constantly change it just for the sake of changing it. You improve it only when it is non-optimal. Assuming you have a well defined idea of what "optimal" is, your code will converge to the optimal point and then changes to it will cease.
Or to put it conversely: there's no better way to guarantee that your product will be non-optimal than to not fix the flaws in it.
What happens when the quirky code you just changed 5 minutes ago had just finished a month of testing and debugging? Or when your architectural re-write has a chain-reaction further downstream?
This is a good point -- you need to consider the implications of the changes you make very carefully. I follow the "fix it when you see it" strategy of the previous poster, and it works well for me -- but then, I am the only one working on the majority of the code, so I'm pretty well aware of why the code was written the way it was, and what the changes will effect.
Re:No easy answer (Score:3, Interesting)
I consider myself a quite competent programmer, but I know from [sometimes painful] experience that simple changes are often not as simple as they first seemed.
I think some people have been overcomplicating (Score:3, Interesting)
Personally I feel the most important thing is to get the superior to 'buy-in' to what you're doing. If time's short and you don't feel the product will be great if done within this limit then tell your boss, explain your reasoning, document what's not going to be perfect and get him to stick his name to it.
This actually helps in two ways, if it does all go wrong you have a very good defense (I told you so), but more likely your boss will get the initial constraints altered e.g. explain the situation to the client.
Occasionally when time is short and the work is urgently required you're going to have to release a buggy mess of code. My personal advice is to get working on a point release of it the moment the original has left your hands. It'll take a while for the code to be implemented and the bugs surface. If the moment the user reports a problem you can produce a lovely working upgrade then they'll be impressed with your customer support and you can sleep at night.
Don't Believe Them! (Score:2, Interesting)
I once worked for a games company that asked me to take an existing text-only game, hack a graphic user interface onto the output routines, and produce a more up-to-date version of the same game. I told my bosses that it would work, once. The resulting code would be ready quickly but would be an unmaintainable mess, and unusable in other products. "Fine" they said, "Its just a market test".
Nine months later I'm in hot water because I'm insisting that the Version 1 code for the game is unsuitable for use in Version 2, and needs to be rewritten.
I have, since that time, had so many jobs in which I was required to maintain 'quick-and-dirty' code which ended up being legacy code, that I no longer believe anyone who says something is throwaway. I always try to make the code be portable and maintainable, because all too often, I'm the one who ends up having to port and/or maintain it.
Dirty coding isn't quicker (Score:2, Interesting)
You may need to try several algorithms to prove which one is the best, but this becomes instinctive with experience. Soon you will not need to code several approaches; just list the options, picture the code in your head, and drop the longer ones.
Back in college (1989), my C teacher enjoyed my homework code because it was less than one page while the other students turned in 4 or more pages. A good portion of it was pointers and the ability in C to make one-line "for" loops that moved blocks of memory. I had to comment each line, because they were so cryptic that I would forget what they did before the code was done. But the programs were short, worked, and were maintainable with the comments.
Yesterday at a client, I refactored some code. A few minutes earlier I had copied a function to make it work with a different global list. (The lists hold configuration data, so globals make sense. And the code is loaded for each run, so there is no chance of contaminating other portions of the app.) This was now the third copy of almost identical code. AFTER PROVING THE NEW FUNCTIONALITY WORKED, I made a generic function that took the list as a parameter and replaced the calls. Tested again, then removed the original functions.
- The original code worked. It was not "dirty". But the new code is shorter and more maintainable.
In the last week, we made a major architectural algorithm change to my company's product. The original code split a request into two parts, handled each request separately, then merged the results. This was "dirty" because a hack was needed to make transfer data from one portion of the request to the other during the merge. But it worked for the last 2 years: it allowed us to write the lower level code, and it did not affect the functionality.
- We just added functionality where the hack would interfere. Now the requests must be handled as one. Because all of the lower level functionality existed, we were able to make the change with about 40 lines of code, replacing over 100 lines. There is still code that refers to the hack which will never be triggered because the input will never have the hacked parameters. We will remove the obsolete code AFTER the next release to save the need to retest many of the modules. (We are really close to the next release.)
- This hack was almost "quick and dirty". It was done because at the time it was designed, none of the lower level code was available, and we could not envision how to integrate the two requests, and there was no need for them to be integrated. The hack to merge the data was added when we realized some data from one request was needed by the other, but it was extremely simple to pass the data. We remained aware of the issue, and were ready to "fix" it when some functionality required the integration. Since the separation occurred at a very high level, and everything was planned with awareness that this change would come, the integration was accomplished quickly.
- We spent 2 days planning the change before writing any code. Because of this, the code took about 3 hours to implement. If we had just sat down and started coding, we would still be working on it, and probably have a buggy mess. Another benefit is that the new code is shorter and more maintainable.
Better design always requires less code, which requires less development effort.
I try not to write code the same day the specs are given to me. Tell the PHBs that the code will be need to wait for tomorrow. Your subconcious will work on it while you sleep, and the solution should be better, cleaner, and SHORTER.
Re:No easy answer (Score:1, Interesting)
We've lost the concept of "prototype" (Score:3, Interesting)
So, you slap something together and you show it to them and say, "So is this what you were thinking about?" Usually they'll say, almost, but I want this different, and what about this feature, and why is that button over there...so on and so forth.
Frankly I believe we used to call this prototyping. Now, in the real world it is easy to see that a prototype is a jury-rigged thing that will fall apart if you push it too hard. In the computer-world if the GUI looks polished than the program must obviously be done.
This is probably responsible for more things remaining Q&D than anything else. (Though some blame belongs with us programmers who don't always like doing the cleaning up work.)
Maybe we need the graphical equivalent of duct tape on the prototype's GUI so people realize that it IS in fact a prototype.
The Situation Dictates The Choice (Score:2, Interesting)
LIMA, Peru (Reuters) - Lacking the proper instruments, a Peruvian doctor at a state hospital in the Andean highlands used a drill and pliers to perform brain surgery on a man who had been injured in a fight, the doctor said on Thursday.
"We have no (neurosurgical) instruments at the hospital.
The patient, Centeno Quispe, 47, had arrived at the hospital in Andahuaylas, 240 miles southeast of Lima, after being hit in the head with a metal object in a street fight, Venero said.
"I drilled holes in his skull in a circle, leaving spaces of 5 millimeters, took out the bone with the pliers and removed the clots that were putting pressure on his brain," he said.
Andahuaylas is one of the poorest regions of Peru, a country in which more than half its 27 million people live below the poverty line.
Venero, who earns $430 a month, said he had used tools from a hardware store on five previous occasions but for less serious operations.
Quispe was making a good recovery in a hospital in Peru's capital, Lima. "
Re:No easy answer (Score:1, Interesting)
Senior member of 10 person development team is also responsible for to system support (hardware and software) for a single shared development system . You can make your own judgements on the wisdom of this (who's doing the support, and what they are supporting).
In the middle of the project from hell (the time/cost overruns are already going into 3 digit precentages), the development system's file system self destructs.
Backups of the project files and home directories exists, but the rest of the system has not been backed up in months. All the software used for development has to be re-installed, and configured (configuration files wern't backed up either).
Senior team member also takes this opportunity to reorganise how the entire systems is put together, because s/he never liked the way that s/he had done it in the first place.
RealWorld result: 10 developers were effectively siting on their thumbs for the better part of a week, waiting for the system to be back in a state where they can be doing real work again; and spend another week at about 50% while some of the secondary software (it was needed, but other things could be worked on in the mean time) are installed and reorganised.
10 develoers * 60 hours of lost productiviy * $100/hour(*) = $60,000 -> That would have easily paid for a propper sysadmin, and a backup development system.
(*) I don't know what the exact consulting rate was, but that is close enough for the effect I want.
PHB result: Senior team member who neglected/forgot to do the backups got promoted for saving the company from certain disaster. Other team memebers begin to leave through a variety of other means (attrition, disgust, downsizing, etc.)
It's true - I heard it from a FOAF.