|
The source of `bad code'
This thought came about in regards to the recent thread "Attending top university and writing good code". Apologies if this is considered redundant.
It is my belief that nasty code is often a symptom of a much greater organizational problem, rather than being the oft-claimed result of any one or two programmers. I say this a bit self-defensively as I know for a fact that I've left some incredibly nasty code at one former workplace: Deplorable, uncommented, spaghetti code following a hypothetical "Worst Practices" manual to the letter. Featuring giant blocks of non-working functionality (I was hashing out ideas, or in the middle of implementing something when something more important came up), and such a huge set of embedded assumptions, each revisit to this code left me (and anyone else) scratching my head wondering how in the world it ever worked in the first place, fearful of touching one of the seemingly fragile foundation blocks. Indeed this code was so academically bad, and the organization had such a lack of desire to ever replace it (it worked so there was always bigger fish to fry), that it eventually led to my departure -- there is only so many knocks you can hear by people who spend months without producing anything, and whose domain is the stunningly trivial, criticizing why you used an early return in one of the functions in a program developed in a week and operating in years in production, or why you didn't use the cool features of DHTML when your web app was developed back when IE 3 just hit the market and your clients used Netscape 3) before you start to get a little, err, angry and bitter.
How did such code come into being in the first place? To start, it wasn't a sanctioned project until after the fact (which is the origins of much of the nasty code in the world) -- In essence I, as a junior programmer, was tasked with performing an absurdly manual process of receiving, validating and "correcting" a load of Excel spreadsheets daily, so after a first stab at automating it via a massive Excel VBA script, I threw together a quick-and-dirty Access database schema and a service application (after being told not to--the sloppy and undocumented manual process was sufficient) to pull the data into a database and perform some "auditing" tasks (which involved the creation of complex inter-relational logic to try to grade data coming from flaky monitoring hardware to basically intelligently massage the crapulent data into something credible). "Great," said the powers that be upon seeing the _incredibly_-rapidly implemented application doing a critical industrial task on a Windows 95 desktop (as the `corporate' network was LANtastic and a couple of Windows 3.1 and 95 machines). "Let's put that in production and we'll start selling it to customers as a service!" "Uh," says the junior programmer, reservedly. "This really wasn't production code..." The manager quickly responds "Get to working on some shiny parts of it immediately. The code works doesn't it?"
And so began the history of a giant heap of sloppy, yet effectively and efficiently working and revenue-producing, code (and corresponding database architecture) that hung around for years (it's probably still there...), slowly tentacling out with more features as the base set of code was never refactored, but functionality was grafted on. To make matters worse, because of extremely short timelines, and a lack of knowledge by all involved (organizationally), the project was basically a continuing R&D project -- most of the knowledge on how to audit the data was pioneered hilaiously in the implementation. Many future projects came about in much the same way -- someone asks the programmer what can be done, and then requests a prototype, and then after they see it and decide that, hell, it's production. You then get the "spec" which is basically some screenshots and descriptions of your prototype.
The point of all of this is not some sort of self-justification, nor is it to justify crap code, but rather is a simple statement that you can't judge all code equally. Don't compare R&D "edge of knowledge" code developed in 40 man hours using antiquated tools on a mediocre platform with the code for a C.R.U.D."so trivial it should have been outsourced or done by a script" data component developed in 800 man hours. Since then I've never been in the same situation and my code generally is gorgeously componentized, appropriately commented, versatile code following all best practices, but that is the result of an appropriate process and sufficient sponsorship, yet I will never apologize for that initial implementation.
Comments?
Anonymizer
Tuesday, January 20, 2004
I think you've got it right. When you're trying out new ideas or testing some new approach, it's ridiculous to spend a lot of time making pretty code (because you're just going to change it in a few minutes when you find out that the particular path of thinking you were going down was flawed and you have to backtrack).
On the other hand, if you've got some software that you've got to maintain and expand for some population of users based on a proven foundation, the core had better be beautiful or your project won't scale with large numbers of users.
Managers who want to push a product out when it's "just barely working" have the wrong idea (unless they're just trying to see if anybody cares about the concept in the first place). The minute you get back a single feature request from your user population, you have to start considering the internal beauty of your product.
JMHO
K
Tuesday, January 20, 2004
Well your initial comment about bad code originating from a larger organizational problem caused me to ask the question, do disorganized people generate organized code? Now by disorganized, your work environment my be disorganized, or your home environment may be disorganized, or maybe your scheduling is disorganized, but if some portion of your life is organized, then I think you fall into the organized category. By disorganized I mean if your work & home is disorganized, and if you are always late to or missing appointments, etc.
In response to bad code growing out of proof of concept, I agree. It's like the adage build one to throw it away. Problem is, after a company has built one, they don't want to throw it away, then your spaghetti just gets more and more tangled as you add more noodles.
Elephant
Tuesday, January 20, 2004
Very good points. My previous employer had no emphasis in quality and it showed at every level. This did not mean I produced bad code because everybody else was doing it, but rather estimates on quality solutions were disgarded for a more favorable completion date. Often you have to do the best you can with the time you have.
m
Tuesday, January 20, 2004
Try not to write test code as a complete application.
Write small, manageable console applications that just do one bit. Make main() call the bit of code that program is meant to test. You can take all the functions() from the test code and combine them at the end and do reorg and cleanup as necessary. You never have anything that completely "works", only enough code to prove the concept.
Andy in Austin
Tuesday, January 20, 2004
One would think, that after so many "bad code becomes maintenance headache" stories, people would realize that writing "bad code" never makes sense. It does not take much more effort to create code of reasonable quality. This effort has a few hefty paybacks: 1) people learn how to write quality code, 2) writing "good" code becomes habit, 3) debugging and enhancing the product is typically vastly easier, 4) it avoids the disaster of having "bad code" become a long-lived project.
Never write bad code.
njkayaker
Tuesday, January 20, 2004
In my limited experience it's true of immature developers: immature developers need a good development process around them, created by their management and their more experienced peers; contrast this with mature developers (or contractors), who have internalised good process and who even if the environment at a new company is chaotic can produce 'good code'.
Christopher Wells
Tuesday, January 20, 2004
"it avoids the disaster of having "bad code" become a long-lived project.
Never write bad code."
Disaster...funny. The humorous thing is if this rapidly designed first prototype didn't see the light of day, this project would never have been green lighted. This project, which produced revenue for years (and is likely _still_ producing revenue), is what funded the team of future developers who then raised their eyebrows and proclaimed how no one should ever write `bad code'. This "disaster" was an overwhelming success from a product perspective, but it's amazing how some code maintainer can come along and call it a disaster because the variables don't follow the current naming convention, or there are some string literals rather than constants.
Secondly the standard proclamation that "quality code" (in an academic sense -- I've never stated that the original code was of a runtime poor quality. In fact it ran perfectly around the clock for months on end until a new circumstance came up that had to be accommodated) is only slightly costlier than "bad code" is delusional. In this case, like in many projects, the code was the canvas and neither I, or the customer, or any peer, really knew what we could accomplish, or what we should accomplish, and as we built we learned and adapted. That's the world of real coding in the non-obvious code world, and it's a world where things generally start out rather unpleasant, and then evolve through refactoring into beautiful, well adapted code. The problem in this case was that management solidified the effort early on and the refactoring process never took place, so years later I had to bear the burden of this "bad code".
Anonymizer
Tuesday, January 20, 2004
To be the devil's advocate:
The purpose of a business is to make money, and if the uncommented spaghetti code can be sold for something more than the salary of the programmer that wrote it, that is good. If, somewhere down the line, there is a large charge, due to its confusing nature, for the cost of adding features, or rewriting it, then the charge can be passed on to the users in upgrade fees. Don't confuse business with computer science, academics or non-financial logic.
Barry Sperling
Tuesday, January 20, 2004
Barry: I like your response, but on the other side I also feel that if a company only focus on making money without checking their "internal" quality, well than it's a short term money-making, and probably after a period of time they won't be able to sell the sh.t.
But, yes, sometimes you do not need nice looking code, you want to solve a problem today and that's it.
Tuesday, January 20, 2004
To say that bad code arises only from demoware that is impressed into a product offering is an incomplete statement.
I think good code and bad code closely resemble the old maxim about happy vs dysfunctional families. IE, the ways in which "good" code can be developed are rather limited and constrained, but the ways in which developed code can be considered "bad" are almost infinite.
Good code arises from great specifications, clarity of purpose, singular vision, highly experienced competence that reduces complexity down to a few general rules, enough time to do things correctly, and excellent technical skills. You've gotta have it *all* or the project is compromised. Bad code arises from absence or the outright perversion of any one or more of these attributes.
IE: right now I am grappling with returning to work on a completely FUBARed product offering that the company owner has decided is a test of his character and personal greatness. The owner is a wholly incompetent and inexperienced hack who has decided that he is the world's greatest developer. Every lousy design decision on his part is excused with some "good reason that makes business sense". So in this instance, the code is righteously bad because someone with absolute power over the project has decreed that any way that he decides to do things is correct and that no dissent is tolerated.
Bad code is a very old story.
Bored Bystander
Tuesday, January 20, 2004
Wait, let me get this straight. Bad code is short-term thinking? Wow, this is totally incongruent with how modern business has decided to operate with long-term investment in their people, products, and technologies... I wish!
They value immediate return, not I. This unfortunately gets reflected in the purpose of a project, the requirements gathered, the time commited, the code produced, the level of testing, the training of users and the quality of the deployment.
m
Tuesday, January 20, 2004
My own take on this is that's it's not so hard to write good code in the first place, but that it's pretty easy to slip into "crappy code mode" when you're just trying things out, or when you're under intense time pressure.
Here are a few specific indicators that it pays to look out for:
1. Never copy and paste more than one or two lines of code. I've seriously considered writing a macro for my editor that displays an "are you sure you want to do this?" dialog whenever the "copy" command is used.
Of all the crappy code I've ever had to deal with, the vast majority has suffered from "cut-and-paste" disease. This is where there are big blocks of nearly identical code, with subtle differences between them.
When you're trying to figure out what's going on in all that spaghetti, it's really a drag to have to try to figure out if the code is different on purpose, or if it just didn't all get updated the last time the file was edited.
2. Set an arbitrary limit for the maximum size a single function can be (50 lines?), and enforce it by splitting up any function that gets near that size.
Spending 30 seconds thinking about *why* this is becoming one large indivisible function might be enlightening.
3. Always check for the success or failure of every operation, and always return a status code from any function that can fail.
You don't need to do a sophisticated check of every return value, but a simple if (retval!=0) perror("something") will go a long way towards making sure that any unexpected errors at least get noticed.
4. Minimize global visibility.
Yeah, I know, we all know better than than to use global variables. I find that my variable discipline is a lot worse in scripting languages than compiled ones for some reason.
Seriously consider whether every function in your module needs to have global visibility, too. If you write a routine that's really sensitive to the conditions it runs under, you probably ought not to have other folks calling it.
Not that I always follow these principles, but when I do, it really helps to ease the transition from prototype to deployable code.
-Mark
Mark Bessey
Tuesday, January 20, 2004
during the dotcom era, we developed a software for a dotcom. one day they ask for specification, they wanted code review, etc.
at the end of their struggling, when they realized that they do not have too many clients and wanted to add as many features as possible they said (with these words):
"We know it's not good, but don't do spec, do copy and paste coding, it doesn't matter".
The internal name of the project was Nike ... Just do it
Tuesday, January 20, 2004
I think the OP's problem originated with himself and the fact that he didn't design anything beforehand. Or at least he doesn't mention it.
"Trying things out" is ok but it is not an excuse. When it comes down to it you are responsible for what you do. "The organization made me do it", doesn't cut it.
Maybe
Tuesday, January 20, 2004
"I think the OP's problem originated with himself and the fact that he didn't design anything beforehand."
This is pretty much the whole spirit of agile software development -- you really don't know what you're going to do until you're doing it (unless you're covering well covered territory, which is when you should be using code reuse anyways), and any amount of pre-planning will often be prepatory waste. I've worked on a lot of teams that carefully (and hilariously) made complex inheritance models and interfaces when all of the information wasn't available (note that in this case there was no `customer' involvement because it wasn't even a sanctioned project -- obviously this wasn't a clearly specified project), and all of this pre-work ends up being a huge hindrance because you end up fighting against it until eventually you go back and change everything.
This is why the oft stated premise of "build one to throw away" often yields the _BEST_ code by far (Dramatically better than the 'the first will be the blessed child").
Anonymizer
Tuesday, January 20, 2004
I'm not talking about drawing up complex UML diagram and inheritance hierarchies etc etc. I'm talking about simply thinking the problem through and making a simply functional and design spec. explaining how you think it will work etc and after that then experiment and "make one to throw away" while updating the spec, but I think you have to have a clear direction first. Just my $0.02 and not trying to offend anyone.
Maybe
Tuesday, January 20, 2004
Does "build one to throw away" really produce the "best" code? How many people actually do it?
In the 20th Anniversary edition of The Mythical Man Month, Fred Brooks writes that his original assertion to "build one to throw away" was wrong, so I thought that idea was somewhat out of style :)
Mike Treit
Tuesday, January 20, 2004
'Fred Brooks writes that his original assertion to "build one to throw away" was wrong, so I thought that idea was somewhat out of style'
A single book hardly defines what is in or out of style, however nowadays it is true that you really don't build one to throw away. Instead you anticipate significant rewriting (err...refactoring) -- in effect it is exactly the same thing. Many edge projects (again, this excludes projects that are doing what should be done via an automation script, which unfortunately is the `programming' that a lot of people are doing and is why they're so willing to proclaim that everything should be so clear at the outset), if you analyzed the source control, would show virtually nothing in common between a close-to-production version and an early version, or such is my experience in a lot of teams.
Anonymizer
Tuesday, January 20, 2004
My experience of build one to throw away indicates that it's not right for all cases, but for many it is.
An example of one instance where it is a good idea, is overcoming a learning curve. I was once working with a product from a company called ilog. The have Java libraries for graphical modeling of data. Their documentation was good, but their was no good tutorial. Great coverage of the API, but not much to get your feet wet with.
Management asked us to review the product, see if it could do X, Y, and Z. They gave us a couple weeks to make the determination. Under the impression that we were merely reviewing the product to see if it would accomplish what they had in mind, we built a quick demo that accomplished the necessary tasks. We showed management that it was capable of doing what they wanted, next thing you know, they've gone and sold our demo code (and claimed additional capabilities) to a customer.
Before you know it, the code went as is into our product. I'm not saying it didn't work, but, if we ever needed to change anything, the code was not designed for any sort of flexibility. It was made to demo X, Y, and Z for an internal query into a 3rd party product, and served the purpose of my team getting over the products learning curve. It wasn't efficient, elegant, or maintainable.
Here we got screwed by management. Not knowing the products capabilities, we should have built one to figure out what it could do, then with that knowledge in mind, design one from the ground up that accomplished what we needed keeping flexibility, maintainability, and efficieny in mind.
Instead, I switched jobs when a new client needed changes, and things were clearly tanking. From what I hear, I made a very good decision.
Elephant
Tuesday, January 20, 2004
The problem is not the wet dream of some non-developer sales/marketing person on seeing something crushed together in a few hours, detecting the gleam of the diamond in the rough and then selling it.
The problem is then that someone doesn't say 'before we ship we refactor to shrink wrap' and make that decision stick. I've seen some CTO/Technical Directors wimp out on that and then paid and paid forever more after.
There is an easier way out of this and that's to never break the rule of 'Thou shalt not prototype' with its brother 'Thou shalt not demonstrate that which doth not exist'.
But this is not the cause of bad code. Occasionally, in some rare magic times when the requirements were as stated (and not some Bizarro mirror image of reality), I have produced beautiful, elegant code that did what was required, did what it said on the tin and I was exceeding glad (and on the whole the client/company couldn't tell the difference from it and dingo's droppings).
But often, the requirements do more closely resemble a Hollywood set of a ghost town instead of a brand spanking, well planned metropolis and I start out on my happy way structuring that which seems to cleave into structures and weaving that which appears to be webbing.
And then tear it all down and start again because its just wrong and ugly and doesn't do anything except depress me.
If I'm in a really bad way a client or someone else might get to see it before I realise its the Bride of Frankenstein and then all my years experience do is give me a number of ways to frankly concede its crap.
But you move on and do it right and whilst it might not be a towering edifice of pixels and interlocking SQL, it might rather be a small cottage, a little shabby here and there, a trifle worn; it keeps the rain out and does the job it was made for.
The painful tune I play over and over, I am crap, therefore I am good.
Simon Lucy
Tuesday, January 20, 2004
Why would one trust an important product that is characterizable as "wondering how in the world it ever worked in the first place, fearful of touching one of the seemingly fragile foundation blocks"?
I have found the "it's crappy code but it works" notion tends to be delusional.
Even when management agrees to "throw one away", they often will change their minds once it appears there is a working product ("why rebuild it when we have one that works?").
njkayaker
Tuesday, January 20, 2004
For those of you defending crappy code, you seem to believe that the only reason for writing not crappy code is future maintainability.
Well, I've dealt with (and am dealing with) crappy code that is also pathetically slow and full of bugs. Fixing the performance is a monstrous chore because code that does the same or almost (but not quite) the same thing is copy and pasted myriad times. Finding out the cause of bugs suffers from the same problems.
So the original poster seems to be citing an example of code that, although crappy, performed well enough and with few enough bugs to make customers and bosses happy. But a lot of times crappy code just makes for crappy, slow, buggy, hard-to-use programs, that take longer to reach a state that makes customers happy and bosses excited than not-crappy code.
Jim Rankin
Tuesday, January 20, 2004
There's two sources of bad code in my experience:
1) When the scope of the code is so complex that one person can't grasp everything, people start duplicating functions not knowing the other already exists, or they cut and paste because they don't know how to get to that code from the where they are in the class heirarchy. (This happens to good people with good designs, too).
2) Programmers unclear on the concept. They just don't get it. They don't think like an engineer, or a sane, rational person. Where do these people come from? They go with the first solution that pops in their head and write it and move on. Then when they're told it only solves 90 percent of the cases so we have a ton of bugs from the other 10 percent, they squawk like a bird and run around the office and call meetings and ask people to brainstorm with them how they're going to handle the other 10 percent that their faulty solution doesn't cover. Then they end up hardcoding constants and putting in a bunch of if-statement special cases which still doesn't cover it all, but they get promoted for being a problem solver and you get stuck with it.
Cubist
Tuesday, January 20, 2004
"Then when they're told it only solves 90 percent of the cases so we have a ton of bugs from the other 10 percent, they squawk like a bird and run around the office and call meetings and ask people to brainstorm with them how they're going to handle the other 10 percent that their faulty solution doesn't cover."
This sounds like a requirements gathering issue and has nothing whatsoever to do with whether the programmer "thinks like an engineer". No engineer is asked to build a bridge, and then a week later told that "Hey, maybe it should fly too". While it's easy to say that the developer should just do all of the requirements gathering to know every case that's simplistic and denies what the user community is really like.
"Then they end up hardcoding constants and putting in a bunch of if-statement special cases which still doesn't cover it all, but they get promoted for being a problem solver and you get stuck with it."
The alternative is that you get the developer that, err, "thinks like an engineer" (an engineer on drugs that is), so they have to build every piece of code to handle every possible imaginable scenario, taking an absolutely simple need and extrapolating it to a massive bulk of carefully designed, clearly commented, but thoroughly unnecessary code. Of course the reality is that such projects never actually come to fruition, and are always one step away from perfection. This is one of the reasons these people feel so righteous in picking on all of the code around them -- they themselves have absolutely no "body of work" to be criticized (and such has been my experience with the `code critics' out there).
Anonymizer
Tuesday, January 20, 2004
Anonymizer, requirements only describe functionality, not how you intend to implement that functionality. If your implementation only covers 99 percent of the possible cases, the customer is going to find that one percent probably the first day, and it will not be enough to say "that's not how you told us you were going to use it." They will be on the phone demanding a fix and witholding payment... so why not cover 100% of the possibilities the first time? Maybe that pointer WILL be null some day, why not handle it gracefully instead of crashing out?
Cubist
Wednesday, January 21, 2004
If it compiles, ship it!
.
Wednesday, January 21, 2004
"If it compiles, ship it!"
This outdated modus operandi has long since been replaced by "If it compiles, patent it, ship it!"
Just me (Sir to you)
Wednesday, January 21, 2004
Brad:
" Cut-and-paste disease"
YES ! YES ! YES !
" arbitrary limit to functions ( 50 line?)"
I would say 'one function' = 'one task'. Combined with proper factoring functions one get a non-arbitrary criteria. Source length is heavily language dependant, if nothing else; I know a language where ( the equivalent of ) functions are typically one or two lines long.
Personnaly I wasn't taught at Uni the very basic rules you gave; I learned them from my readings for a hobby software project. Another thread here confirmed my guess that I'm not the only one.
Astrobe
Wednesday, January 21, 2004
You know, especially when you're just trying stuff out, writing beautiful code from the get-go feels just like beginning your grocery list with an illuminated letter. No wonder it seems like a waste of time.
But oh, how quickly the effort is rewarded. If you're trying to write beautifully every step of the way, you're forced to think carefully about everything you're doing. "/* This is a method to..." ... uh ... to do what? No, wait, if it does that I also need a function to handle this.
You have far fewer chances to write anything so bozotic that you have to rip out major sections and start again. Sure there'll be debugging but you will benefit from the clarity of thought that went into your work so far.
Not saying the OP did anything wrong, just saying that there's so much right with keeping your code sparkling clean even when it seems unnecessary.
Fernanda Stickpot
Wednesday, January 21, 2004
"You know, especially when you're just trying stuff out, writing beautiful code from the get-go feels just like beginning your grocery list with an illuminated letter."
Why? Why does it take longer, or more effort, to write beautiful code than crappy code?
I mean, I've seen lots of crappy code where I say to myself "it takes a lot of work to write code this bad". A lot of times, crappy code takes 500 or 1000 lines of code to accomplish what beautiful code can accomplish in 50 or 100 (or even 10).
Doesn't it take less time and effort to write 100 beautiful lines of code than 1000 crappy ones, even if it means you need to stop and think a little before you type?
Jim Rankin
Wednesday, January 21, 2004
(And yes, Fernanda, I know you were actually advocating for beautiful code. But I'm going farther in saying the truly Lazy programmer doesn't write crappy code in the first place because it's just too much effort.)
Jim Rankin
Wednesday, January 21, 2004
"But I'm going farther in saying the truly Lazy programmer doesn't write crappy code in the first place because it's just too much effort"
Pick an argument and stick to it -- your first point was to refute Fernanda (who said that it's just a bit more effort to write great code) and proclaim that it's actually less effort to create great code, and then you call those who create crappy code "lazy". Wouldn't they be the harder working of the two? :-)
However, as stated eloquently by others previously, there is a vast span in what is defined as "good code". To some people good code is code that is conforming to all organizational variable naming conventions (the project mentioned survived several iterations of said standards, and it was always hilarious when some code monkey would make a big show out of changing vast swaths of code to conform with the new standard ["This damn rogue code with camelback variable names! We use hungarian pascal style now!"], invariably leaving 75% of it with the old standards that died before it), or hearty commenting using a standard comment block before each function redundantly expressing what the data type is of each of the parameters for those who don't understand parameter declarations, or perhaps good code means that every data table access had the creation and registration and use of a swath of COM+ hosted middleware components. Hell, I've heard people call more advanced code (compression, encryption, etc) "bad code" because they, in their incredibly limited knowledge, couldn't personally understand exactly what it was doing without sitting down and dedicating some time to understanding it (and even then it was unlikely).
It's for this reason that almost every programmer assigned to an existing library of code defines said code as garbage -- it's so easy to do.
Anonymizer
Wednesday, January 21, 2004
"A lot of times, crappy code takes 500 or 1000 lines of code to accomplish what beautiful code can accomplish in 50 or 100 (or even 10)."
Is this why we are viewed as factory workers? Does think time not count in the 50-100 lines of code. I would guess that 50-100 lines of code involved some thought or design beforehand as opposed to the 500-1000 lines, which probably involved a carefree brain dump.
Not to say that it would take more time, but lines of code is not a good measure of speed or effort.
m
Wednesday, January 21, 2004
The most effective "build one to throw away" system I've ever seen is building half of one to throw away. Here's what we end up doing.
Go beyond what the earlier poster said about functions and main(), and do the exploratory use of COM+ distributed multithreading by building a COM+ distributed multithreaded..."hello world" program. Write a separate "hello world" program for every feature you want to experiment with, or test. Keep it around until you've incorporated that feature into the main program, then trash it. Resist the urge to graft multiple "hello world" programs together. Copy and paste and then diverge if you have to -- you're throwing them both away in the end, right?
It's actually one of the few best practices that works in my environment. Because, well, it's impossible for management to ship "hello world." We don't necessarily have time to do as good a job as we want to on the real product, but having "scratch paper" that won't be converted into shipping code does help.
Mikayla
Thursday, January 22, 2004
'"You know, especially when you're just trying stuff out, writing beautiful code from the get-go feels just like beginning your grocery list with an illuminated letter."
'Why? Why does it take longer, or more effort, to write beautiful code than crappy code?'
Note that I said 'feels just like', not 'is just like'. Undoubtedly the total amount of time spent on beautiful code, from design to maintenance, is less than, or no more than, that spent on crappy code. That's partly why it's beautiful. However, especially when you have customers on your back or are just whipping up a prototype, writing a beautiful first few lines often feels OTT. Doesn't mean it is.
Fernanda Stickpot
Friday, January 23, 2004
 Recent Topics
Fog Creek Home
|
