Mr. Z was the black-and-white darkroom instructor at one of the top-rated schools of photography. In one class, he picked out a negative from each student's portfolio and said, "Print this." One would-be professional photographer burned and dodged, spilled fixer all over himself, and proudly showed the results to the instructor. Mr. Z glanced at the printed photograph and said, "It's too dark. Try again." On the next attempt, Mr. Z said, "Not enough contrast. Print it again." Iterate until exhaustion.
Finally, after the student's clothes were permanently impregnated with the smell of fixer, Mr Z. approved of the photo. "Very good!" he said. "Now, throw it away."
"What?!" replied the student. "You just said the photo was good!" Mr. Z responded, "It is printed very well. Very good technically. But it's an uninteresting subject. Throw it away."
That lesson stayed with the photographer—who later spent a few years as a black-and-white darkroom manager—but it's one that developers need to learn, too. Just because your code works doesn't mean it's done. Your application might meet the specs. But that won't make it great.
That working app won't make you a better programmer, either. Because I've come to believe that all great software is written three times. The first time you write it, it's to see if your idea can work at all. It's the digital equivalent of scratching something out on the back of the envelope, leaving out the fancy stuff and just concentrating on the basic feature or algorithm. Once you figure out that yes, this might be a good way to solve the problem, then you write the code a second time, to "make it work." But it's the third time you write the code, when you've had the opportunity to learn from the mistakes from the "try to make it work" phase, when your application will be the best it can be. (Well, almost. There's often a 3.1, too. Even great software has a few bugs.)
Don't trust me on this? Look at all the "best of" software you ever worked with. I sure didn't love Window 3.1, but it was certainly the apex of Microsoft's vision and architecture of the time. That "third try" might not have a 3.0 or 3.1 version number, depending on marketing decisions (it used to be easier to get someone to upgrade from 4.0 to 5.0 than to pay real cash for 4.1) and on the nature of the development community (particularly in the open source universe) which is happy to trundle along for years with version 0.23 no many how many design iterations the code has gone through.
Not all great software has a Version 3 sticker, because sometimes the development staff get to throw away version 1 or 2 before the product is launched. But look at the software you most loved, before it was overloaded with feature-itis. I betcha it was the third try.
The hard part, though, is learning to throw out code and start over. It always seems easier to edit and debug the code you've written, but every brilliant programmer I've known (and I've known quite a few!) has talked about the need to start with a clean editor screen and write the routine anew, without reference to the old code. It's long been a tenet at the Schindler bitranch that when you find a block of code with several bugs, it's time to dump the whole file and write it again from scratch. It's faster than trying to squash all the bugs in your bug factory. Because bugs do tend to congregate, and hide behind one another.
Maybe it's because the initial design premise for that block of code was wrong, or perhaps it's just because you (or another developer) wrote it with a hangover. But propping up your "quick and dirty" solution by investing more time and effort into it is a fast track to a big ball of mud [1]. If not a doomed project [2].
But for your own career development: The real reason to throw away code and start over is that it forces you to re-think what you're doing, so you have a better chance of discovering a better solution to your problem. As Guido Von Rossum describes in his history of Python [3]:
Sadly, I'm sorry to say that raising an overflow exception was not really the right solution either! At the time, I was stuck on C's rule "operations on numeric type T return a result of type T." This rule was also the reason for my other big mistake in integer semantics: truncating the result of integer division, which I will discuss in a later blog post. In hindsight, I should have made integer operations that overflow promote their result to longs. This is the way that Python works today, but it took a long time to make this transition.
In other words, you do have to re-think some things to make them work better. And you won't do that by "fixing the code" in an existing module.
You might be hollering at the screen by now, telling me that it's all well-and-good for me to tell you that you should be willing to start over, except that in your shop they're all screaming for that app right now, and you can go back and "fix it" later. Except of course you never do get back to it, because there's always the next crisis to deal with. I get that. There are times that responding with a Yes Ma'am is the right approach (because truthfully, not every line of code you write is going to be your best work). And if you're lucky or smart enough to work in an office that lets you add functionality one step at a time, you can often throw out the "wrong" code... one step at a time.
But even in the worst cases, you have to take the attitude that you're the professional, and it's your job to serve your client/user. It might appear to the passenger in the back seat that driving across the parking lot is the fastest way to the entrance, but it's really not the safest or the most efficient route.
And in particular, the Yes Ma'am approach won't help you become a brilliant programmer. Because brilliant programmers are always willing to throw out a "working" solution in order to find a better one.
Links:
[1] http://www.codinghorror.com/blog/archives/001003.html
[2] http://www.javaworld.com/javaworld/jw-12-2008/jw-12-project-death-march.html
[3] http://python-history.blogspot.com/
[4] http://www.linkedin.com/in/edborasky
[5] http://www.onlineflashgames.org
[6] http://blog.criticalresults.com
[7] http://www.sarahmei.com
[8] http://www.joelonsoftware.com/articles/fog0000000069.html
[9] http://www.beginwithdisbelief.com/
[10] http://www.javaworld.com/community/www.beginwithdisbelief.com
[11] http://leftcurlybrace.blogspot.com/
[12] http://leftcurlybrace.blogspot.com/2009/03/code-is-like-waffles-you-should-throw.html
[13] http://www.blogger.com/profile/11974756524348120587
[14] http://www.stevenMsmith.com
[15] http://prajapatij.tripod.com
[16] http://duineframework.org
[17] http://martinfowler.com/books.html#refactoring
Great advice!!
You've hit the nail on the head! Now, just convince management. :)
The freedom to throw things
The freedom to throw things out makes developers braver and more creative. You can always go back to that old branch if you need to.
Version control
"Plan to throw the first one away. You will anyway."
I think you've also hit upon a great reason teams and individual developers need to use version control. When all your past versions are checked into CVS or ClearCase or whatever, you can throw stuff away painlessly. A "trash can" feels so final--but you can always ignore a branch that doesn't work out.
The freedom to throw things out makes developers braver and more creative. You can always go back to that old branch if you need to.
I still find it amazing--but I see it anyway--that professional development teams still attempt to function without some kind of versioning system. You need it for so many reasons.
Why stop at three?
Why stop at three? Every time you solve a problem, your solution will improve. The number of iterations that produces a close-to-optimal solution might be 3 in some cases, but it'll vary between programmers and problem spaces, as well as over time due to tool changes.
Rather than saying three is the magic number, perhaps it would be useful to acknowledge two things:
Your first solution will always be suboptimal. I think we can all agree on that. But, knowing when a solution is optimal is hard. You have to balance simplicity, readability, efficiency, how closely it hews to requirements, and scores of other factors, and the weights of the factors will vary across problem domains.
The important thing is to rewrite at least once. And to convince your manager that "all checkboxes on spec checked" does not mean "optimal."
I don't agree with the
I don't agree with the starting with a blank screen approach. If I can, and that's a big if, I like to go back line by line, and see if I can re-write it. I already know it works so it takes out some of the time I have to test later so I can just spend analyzing my code. If I run out of time at least I can check in my original code. I know that's not the optimal way to do things, but when you got 5 bosses telling you to do what each of them tells you sometimes you don't get the luxery of doing things by the book. Besides I just got a 5% pay cut because of the economy. Doesn't exactly make me want to work harder.
Don't throw everything away
Before throwing away the source code of complete and working applications you should read this:
http://www.joelonsoftware.com/articles/fog0000000069.html [8]
In my opinion it's okay to break the house (application) in pieces, throw away the ugly parts and reconstruct it, but don't rewrite everything from scratch.
Source code files older than about two years falls in three categories:
1.) a perfect and beautyfull piece of code - no need to change it
2.) unused or obsolete code - this is a no brainer, remove it
3.) ugly code, no programmer have had the courage to change this crap - THIS code should thrown away and rebuild from scratch
it is 150% correc
Ya whatever u said is correct right down to the code. It is the third time we find out the best if not the optimized way to achieve anything.
I am now in a project which is in its third phase. i hope it will turn out to be a good product.
www.BeginWithdisBelief.com [10]
True, to a degree
Hi, Esther!
The basic premise of being able to throw away code is absolutely correct. What would you think of someone in any trade or art who valued his output so highly he couldn't bear to part with it?
But I do have some issues.
First: Sometimes you really do grasp a problem right off the bat and hit it out of the park. Subsequent versions are refinements without any real dramatic redesign. I did that with a home-grown DBMS designed around a problem domain I understood very well, in a field I had worked in for ten years.
Second: Any program of any complexity--like Windows--is composed of various parts, and as a programmer, you have different levels of comfort with each part, most likely. Identifying a "version 3" is a little dubious.
Also, MS seems to have a corporate philosophy of not caring about their first couple of versions, whereas a company like id seems to start from scratch every time and produce great, cutting edge software every time.
Third: It's all very well to replace code, but doing so is often a crutch for coders who don't want to do the hard, unglamorous work of maintaining existing code. As Joel says, starting from scratch--which all coders just love to do--means discarding the experience of the former programmers.
Full response on my blog:
http://leftcurlybrace.blogspot.com/2009/03/code-is-like-waffles-you-shou... [12]
Complex or simple system?
Interesting article however it would really depend on you are working on software that is a major system, a sub system of a major system or a simple system.
Simple systems are thrown away most of the time anyway. A sub system rewrite is possible because it won't cause (many) other areas of a software to break. Finally a major system rewrite which is a huge capital expenditure, will introduce new exciting bugs and take a lot of time.
Who Judges Your Brilliance?
Some managers judge brilliance by speed. The faster the delivery, the more the brilliance.
Other managers judge brilliance by cost. The more economical the delivery, the more the brilliance.
Programmers judge brilliance by elegance. The more beautiful the code, the more the brilliance.
Customers judge brilliance by quality. The more value the code brings to them, the more the brilliance.
The ultimate judge of programming brilliance, in my opinion, is you, the programmer. Deciding who you are writing the code to please may help because you won't be able to please everybody.
I haven't been a professional programmer for many years. Looking back, I feel like my best code was the code that pleased my customers. That feeling was followed closely by the code that pleased the programmer inside me. When both the customer and my internal programmer were pleased, I can see now that I was brilliant.
And to the best of my recall, I was brilliant more often when I started over.
I agree, good ideas... with a caveat
I believe the story, and some of the replies are very well done and have great ideas... "planning to through the first one away" is not a new idea in C.S because it is a good one... almost every other field of engineering uses models or prototypes before undertaking any large project. Throwing the first try away is simple creating a model in an agile type of way. However there is a large caveat here that must be addressed. Knowing when to throw something away is not a simple decision. I have known tons of programmers, myself included (usually those with less experience) that throw code away for all the wrong reasons. Getting rid of something because you don't understand it or are arrogant enough to assume that "I can do better then this crap" can often be a tremendous waste of time and can actually hinder you from learning. Sometimes forcing yourself to learn other peoples code (even if it is not optimal) can give you valuable experience into ways of doing things you might not think of on your own. Just be careful when you are throwing it away you are doing so of just and valid reasons.
Ball of Mud?
You say "But propping up your "quick and dirty" solution by investing more time and effort into it is a fast track to a big ball of mud" as if "ball of mud" is a bad thing to have.
When Joel Moses first said "big ball of mud", he was comparing Lisp to APL, the latter of which ("a diamond") can't be added to without ruining it.
Me, I'll take the consistent, extensible system any day. Systems which can't be extended without ruining them don't tend to live very long.
It will never happen...
Having written lots of code over 30 years, I've seen the good, the bad, and the truly ugly.
Given the luxury of starting something over used to be part of the exercise - first you design, then prototype, then execute and supposedly the 1.0 version runs. Version 2.0 gets close, and Version 3.0 was where it was supposed to be when it released the first time.
Then a manager with a fetish for metrics, not results got too clever by half and we got stuck with Rational Rose and other Modeling Management frameworks.
This layer quickly replaced the limited thinking that was occuring at the project/product level and as such lip service is the only thing paid to concept of design/proto/execute. People will argue to the contrary, but I have yet to see a very high success rate from any development group that spends it's time worshiping the modeling and versioning system instead of solving the problem.
Open Source development is one of those bright spots in the world where religious wars can still be fought over emacs vs VIM and work still gets done well, and in a timely manner... :-)
I believe this is a bad idea
An excellent program is one that meets the requirements and nothing more. Programmers will not like this statement, but business people and project managers do.
The purpose of code is to provide value to the end user. Someone gets with the end user and creates the requirements. If the requirements are met by your code, YOU ARE DONE, regardless how pretty you could envisage your code possibly being, given more time.
If after creating version 1 that meets the requirements you then say, "I can make this 'better'", you are saying it's OK to spend more time and money when you could be working on the next application. This makes the application a black hole for over spending and consuming resources.
What does it buy you if you make the application better than the requirements? Nothing. You are saying that you know more then the requirements person, and you are going to do what YOU want, not the end user.
If after you create the application that meets the requirements, and the END USERS says they would like additional functionality, the requirements gatherer will filter the "wants" from the "needs". He will then send a new requirements package to you. Then if you find code that is hard to manage or does not lend itself to the new requirements, you merely refactor.
There is a phrase "good enough programming". This says software is "good enough" when it meets the requirements. If you then say you want to change the requirements or spend time doing things "better" that does not provide end user value as defined by the requirements, you are just wasting your company's money. Some programmers are never satisfied, and software is never good enough, and can constantly be improved. You can certainly make notes about things you would like to change IF you should ever go into certain sections of code. But you should NOT do it unless it is NECESSARY to meet the requirements.
Remember your job is to deliver the most applications to the end users for the absolute lowest cost in the shortest time that meets the requirements.
Nothing more.
Hmmm,
Hmmm, I'm not sure if you see the point to this entry. Its not a question of if you should program extra functionality at all. Writing one version of a program which works isn't enough to weed out issues with efficiency that may not have been seen before, or finding all the small bugs.
Your argument seems to be that people should write only to fit the needs of the end user, as they are the most important asset. But releasing any product of any sort, software or otherwise, that is riddled with inefficiencies, inconsistencies, or other problems caused by unrefined work simply leads to an overall lower sale of future products. Consumers aren't as stupid as you think, and if you release a cruddy project, you'll be remembered for it.
Checking for the efficiency, and effectiveness of code helps assure a consistent quality release and a that is always reflected in sales. Admittedly, there is a time factor, and spending too long on any one thing is never good, but that is the reason for development cycles. Things CAN always be improved, and SHOULD always be improved, as long as it fits.
An excellent program is one
An excellent program is one that meets the requirements and nothing more. Programmers will not like this statement, but business people and project managers do.
Except sometimes its quicker and cleaner to code a generalisation of a given set of requirements than just the requirements themselves. And doubly so when next month's "requirements" will, as likely as not, be just a different subset of the same generalisation.
So whats the conclusion..
Yes, what are you saying is the experience most of we developers (mostly open minded) have. So, whats the conclusion on this? Can we have tools, frameworks or specifications to make it in real world and out of our heads.
Trash can or refactoring?
When I apply new technology or explore new ideas I often use the mentioned approach, it's just playing around and getting experience, or giving a demo of the basics. In most cases I don't reuse that code later.
But when I am working in a team with loads of lines of code in existing products, things get different. Throwing away code is often not an issue, it's too much risk, especially if their are too many dependencies with other parts of the code. That's where I will apply refactoring, inspired by Martin Fowler's book [17] about this subject. This approach is quite different from "fixing the code". It actually forces you to truly "rethink" the code and bring back the design, without breaking the existing system. The true goal is to make the system easy to understand and easy to adapt to changing requirements.
And ..... I don't get a refactoring budget from my manager. It's the developers job to safeguard the design and keep the code clean enough to deal with upcoming requirements.
comp sci college degree = great, useless degree - nice / worthle
Hello I'm one of those guys that went to college for a Comp Sci degree. I always loved computers, technology and programming. Never liked people who went to school for Comp Sci to earn big bucks. It is certainly a great comfort to know that what you love doing, pays well. Its great!
I've met some great, killer coders / programmers, that didn't need a college degree. They were exceptions. One guy had a really low GPA throughout his college career, got the degree just to have something on paper. Got a job very quickly...
On one of my first interviews I couldn't write a simple TreeMap on the spot, in java, not because I didn't know how to do it but because the nervousness of the situation did not allow me to concentrate. The interviewer was impressed with me and my resume so they gave me a chance to write it from home. Yes, I could have had someone else write it but I didn't. I wrote the darn thing and submitted it. It earned me a trial period with the company, I ended up choosing a different, better job anyway.
I love music. A lot of computer programmers, software engineers love music. I used to make music. That's just how our minds work.
Point is, I don't know why would a job posting for a software job require ANY degree. It requires either a specialization or year and years of experience. College degree does prove some level of consistency, some expertise in entry level programming / software engineering. Then again there are people who graduate and still don't know / care about anything. There is no recipe for a great software engineer.
I would say look at the persons extra projects, internships if they are fresh out of software engineering / comp sci - X college, what are their future plans, interests. have they have a blog? they they know the concepts? explain, draw a concept.
If you are in the comp sci profession, without a comp sci, software degree, you are a huge risk taker. REAL degrees in these areas are going to become more and more important (as we compete in a more global economic environment) and you can't learn everything you need to know from howto blogs, mc graw hill programming books and joe the pizza owners php project website. You need some formal education. PERIOD!
There is very few Albert Einsteins out there, patent clerks who make break through discoveries in theoretical physics.