Fog Creek Software
Discussion Board

It's not bashing but pragmatism

    What it comes down to is this: a basic lack of efficiency. As a former engineer, efficiency was paramount. The more complex it is, the harder it is to design, implement and support so it must complete it's function with a minimum of waste. In any field, efficiency is the rule. When I programmed, it had to be compact and neat for the IC's I used. When I started in networking, I had to support machines with Windows software installed and most of the issues encountered were due to unprofessional coding or non-essential data.
    Remember you're first programming class? It may have been Assembler, Q-basic, Fortran or Cobol but the main thing taught was legibility and attention to detail. Code was hard to read without indents and if you were careless with your code, you could either waste time rewriting unworkable code or run the printer paper supply out with an infinite loop if it did work (too embarrassing!). Back then, it was permissable for an undergrad to "eff up" in such fashion because you were still learning but even then, there was still a "right way"-and you had to learn it. In the private sector, that is unaceptable. Timetables need to be met and they can't be when your client's pc is down due to sloppy coding and backups do not exist for their  data (most companies are like this).
    Standardization is difficult when the company that issues the standard is itself holding back progress. How many times must I re-install dll's which were replaced by programs with an out-of date version for the software? The incompatibilities alone are nightmarish without the extras; untraceable error messages (with the help of MS support), incomplete patches (ex. nt4 sp6) and do-it-yourself tweaks, which a lot of programmers I know personally, have had problems with implementing.
    I have seen your test and I must say that I agree wholeheartedly (twelve should be the score for every company), but after that, I cannot understand how you can ignore the flaws in the rest of the industry? If Microsoft cannot live up to your own company's standard in statement and deed, your seemingly unquestioning support for them is an enigma to me (unless they are going to buy you out).

Gary 07/03/2002
Wednesday, July 3, 2002

The above was in response to Strategy Letter IV

Gary 07/03/2002
Wednesday, July 3, 2002

Don't forget to use paragraphs occasionally.

Your Return Key
Wednesday, July 3, 2002

You know, this is why people read Joel's articles.  Could you imagine if his weblog said things like, "Software engineering -- you should do it too!"  Or "Sun is right -- GOTOs have no place in my programs or yours!"  Yuck.

Sometimes you gotta know when to study, and when to spend the night with the teacher.

Wednesday, July 3, 2002

I recently transitioned from a small start-up like company to a much bigger (400ish people) company, and i'm finding myself having to write very clean code.  The problem i'm having is that there seems to be a direct relationship between  "neat and clean" code and advanced, modular,  compact code.  The more efficient my code gets, the messier it looks.  Maybe i'm a bad programmer (i've never considered myself bad)--I  dunno, but lately I continually find myself going "should I make this really fast and messy, or should I just do it simple so my boss will see that it looks pretty".    Any Ideas?

Vincent Marquez
Wednesday, July 3, 2002


Unless you're writing kernel level stuff, neat and clean is almost always the way to go. It's much easier to run profiling software on a program once the application is mostly built out. It may very well be that your portion of the software doesn't need optimization.

Once again, the oft-dreaded 80/20 rule applies. 80% of the time the software will be running through 20% (or less in lots of cases) of the code.


James Wann
Wednesday, July 3, 2002

Above all else, code should be easy to read. Premature optimisation is the root of all evil (and hard-to-read code!).

If you have nice, clean, modular, easy-to-read code that's not fast enough, it's time to profile. Don't try to guess where your code is inefficient - you'll often be wrong. Measure it, and know for sure. Then you can optimise those areas of the code that need it, hiding your messy-but-efficient code behind nice interfaces so everything remains readable.

Optimisation is one of the most common excuses for messy code. And it's usually not necessary.

Darren Collins
Wednesday, July 3, 2002

Gary, the EWD writings mentioned in a recent thread rock.  Many EWDs debate this topic.

Also, from the inventor of Fortran, "Can Programming Be Liberated from the von Neumann Style?"

Talks about how our tools, including fortran, suck.  If we want to improve programming by engineering, we need to look at the tools.  When you talk about how diligence is important, it sends out warning flags that our tools aren't made to deal with complexity.  We keep on using system languages for applications.

Wednesday, July 3, 2002

Exactly what commercial product are talking about that runs too slow here?

Is someone confusing the issue of bloat ware with the issue of speed, and poorly written code?

Processing speed to today is cheaper than water. I am not suggesting in anyway that we stop writing efficient code. However, just what code are we talking about?

Strategy letter IV is about making software, and the fact that writing software with constrains removed frees the developers to concentrate on features.

When you remove the constraints of efficient code, and also remote the constrains of writing without regards to size, then you get a lot of software for the money.

Years ago, software people used be concerned about the timing, and location of their data on the disk drive. By paying careful attention to this detail, one would be able to increase the speed of the their disk reads. We just don’t even think about this stuff anymore!

In the old PC days of dbaseIII software, we would use a record “seek” command. In today’s environment is it quite common to see a WHOLE LINE of sql to retrieve ONE record. I want you folks to think about this! The sql engine is loaded. The sql engine then parses the sql for syntax. The sql engine then builds a query plan, from this query plan the engine decides what index, and the most efficient way to grab the record. THEN the record is retrieved. This whole process of the sql is LARGER THAN ALL of the dbaseIII environment.

If 10 years ago you would have told me the single records would be retrieved via a TEXT interpreted sql, I would have thought you are NUTS. Today, this is COMMON practice. By the way, the little JET engine from Microsoft can easily do the above in a few thousands of a second! Why?, be cause processing is so incredible right now. The other reason is of course that the concepts of data structures have been *removed* from the code, and the data may be on a server on the desk next to you, or half way around the world (but your code does not have to care, or know anymore).

Increases in processing, and disk drives allows a lot of stuff to be done on the cheap. The wide spread use of sql to read a record is a great example of this. It is incredible! A text interpreted string to read ONE REOCRD!

Java today is great example of trading off some speed efficiency for ease of coding. Of course the same thing has always been said about VB vs. C++ also. However, as a thread of mine here showed, the speed of C++ is no better than VB on a per instruction basis anyway. The gains in C++ speed over VB come from HOW you solve the problem...not the actual speed of the code.

For some people, I am sure they think that not worrying about placement of data on the disk drive is a waste. I am sure for some people that allowing developers to code without regards to program size is a waste.

However, it is the consumer that is demands these features.  Over time, it seems that much of the loss of efficient can be re-claimed anyway. c++ vs. VB is a good VB eventually go a native compiler in addition to the p-code compiler.

Many people think that a automatic transmission is a waste of engine efficiently. It is a question of convenience, and how much bang you get for the buck.

If you want real efficiency, then you can hand code your application in assembler. I doubt that any one can finish any kind of commercial project when code is written this way!

Commercial software is all about converting code into dollars. No one is forcing you to drive a Mercedes Benz, or a BMW. Most consumers go with a average car. Most consumers simply cannot justify the extra expense to buy a newer car, or even a higher end car. In fact, a very high percentage of consumers actually save money, and purchase used cars (a good many probably *could* come up with the money...but it is just not worth the extra price for a newer car).

The exact same thing applies to software. Very good, and very tight, and very efficient code cost more money. With the cost of processing and disk drives like is the consumer that is making this decisions. The consumer wants more software at a cheaper prices. In fact, consumers can’t get enough software these days. The software industry has grown from about 0, to 300 billion or more in a very shot time.

Consumers love this stuff, and purchase software by the truck loads.

It is not the software companies driving this is the consumer. Perhaps we should tell consumers not to purchase cheaper cars.

Higher quality code = more cost!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, July 4, 2002


Higher quality code may cost more to build initially, but it can actually be cheaper if you factor in maintenance.  We tend to concentrate on delivering the system and ignore the 5 - 10 years someone (hopefully not us) will have to support the code.

John McQuilling
Thursday, July 4, 2002

A good deal of 'code' written these days barely qualifies as such, for the most part its a set of instructions to another layer of interpretative code, whether functional or declarative.

Stringing together a lot of calls to a third party API regardless of the language, or twiddling a few properties of a class and subclassing an event  is just that.

And I'm not decrying it, I do it myself, I'm quite happy to get lazier and lazier in the actual text of the 'code'.  It does mean ,though,  I have to get better at managing the design.

As for a curve where the greater the efficiency of the code the messier (and less legible by humans) that code is.  Yes that's true.

Its bad only in the sense that someone human has to come along at some time and decide how the code does what it does.  (I'm almost straying into the rewrite argument but I'll avoid it).

The most efficient coding system we know is DNA/RNA and that's a mess.  Its a mess because it evolved.

No code starts out a mess (unless its plainly just wrong), but over time it accretes and adapts to changes in requirement, platform and the like.  It acquires strange circumlocutions and intitialisations.

Its not always possible to scrub out the mess because different platforms for the same code base need different bits of the mess.  (Hmm that rewrite argument is looming).

This is not a defence of  overly complex code, its just a description of how it is.

Simon Lucy
Thursday, July 4, 2002

Your assertion is absolute rubish!!!
DNA/RNA is not only efficient, it's also very elegant.

One would certainly not call it a mess[suggest you review some of your A-level biochemistry]

[The most efficient coding system we know is DNA/RNA and that's a mess. Its a mess because it evolved.

By The Numbers
Thursday, July 4, 2002

As far as developing commercial apps in assembler - I hate to burst the bubbles of any desktop developers by making them think about large systems, but there are still people hammering out assembler code in mainframe environments every day, and meeting commercial schedules.

What's more, much of that code works far more reliably than the code cranked out in nth-generation, strongly-type languages with GC and other such fancyness to protect end users from programmer error.

Rodger Donaldson
Friday, July 5, 2002

Rodger, maybe it's a nitpick -- but targetting a mainframe lets you write more complex programs.  It's not just total control over the machine, but:

- performance is pretty well-known
- few side-effects compared to desktop apps, which are often all about side-effects

I agree though, with the idea that people program in a tower of babel, building code with dependencies.

Friday, July 5, 2002

            Assembler is an extremely robust language which requires the attention to detail I mentioned. As demanding as it is, the finished product will rarely dissapoint when designed properly. Who can say that they don't want well designed products?

            Albert's reply wandered through various analogies without contributing to the topic at hand. How can one justify sloppy work by throwing more horsepower at it? No. Proper design equals well-made product. It is not about speed to me because that can be tweaked later. You cannot tweak code that is unintelligible. Unreconizable code will always lead to mistakes.

            The assertion that the speed gains in recent years justifies bad workmanship is the issue here, not the needs of consumers. I would simply like for someone to ponder that for a moment. Why can't programming adhere to stricter standards? Yes, the marketplace requires cyclic product updates and releases - or does it? Why can't a well made product justify the time that it took to create? It should.

            Run a mainframe with that type of thinking and see how long it takes for you to have an "office session" with your director.

Sunday, July 7, 2002

In almost all of the posts on this board, there is a common thread running underneath most of the topics.  I think it's an attempt to "justify bad workmanship".

Yes, the comments that speed gains help justify sloppiness is just one.  Others include the whiny "should I work more than 40 hours"... "should I work on holidays"... "I need a private office to do my best work"... "we could have quality if only we had more time"... "we need to be protected against H1B"... on, and on, and on.  Put them all together and they are actually quite contradictory.

No, I disagree that it is about "efficiency".  I prefer to do things "effectively". 

I always think... "is it effective to do the wrong thing in an efficient manner"?

Joe AA.
Sunday, July 7, 2002

> How can one justify sloppy work by throwing more
> horsepower at it?

Don't you think you're fighting a straw man?  Does Joel's strategy letter justify sloppy work?  Or is it about an engineering trade-off?

Sunday, July 7, 2002

*  Recent Topics

*  Fog Creek Home