Fog Creek Software
Discussion Board

The "Take What They Give You" Attitude

When programming I continually come up against situations where the programming tools I'm using, the interpeter/compiler, components, or add-ons, don't work quite the way I want them to.  My first inclination is usually to bully on through and try to make them do what what I want the way I want it.  But this is an inclination I almost always try to fight off.  This is because over time I've developed what I call the "take what they give you" attitude toward programming tools.

The clearest example where I did try to bully on through -- before I developed the "take what they give you" attitude --happened to me way back in the late '80's when I was basically a power user writing my first database app using Paradox for DOS. 

Paradox for DOS was a bit ahead of its time and was one of the first desktop databases that worked with sets of records and displayed them in a grid.  The main user interface of my application was centered around a pair of grids, and I wanted for the current record in each grid to be highlighted by a solid bar that went across all the fields, instead of just by a simple blinking cursor in the active field.  Well, I made it work the way I wanted, but that decision came back to haunt me.  First, I had to manage a lot of things in code to make sure a selection bar would always show across the active record.  Second, and more importantly, the prestidigitation that I did in the code to make the select bar appear involved (as I recall now) changing states of the grid from browse to edit, or something like that.  This created the need to continually do checks in code for what the status of the grid was whenever the user tried to do an operation, or returned from doing an operation somewhere else.  And it ended up creating lots of bugs.  I can still remember late night calls and not wanting to answer the telephone, when late-night users discovered yet another problem, which nine times out of ten I could track down to the code I had added to implement the solid select bar.

And all those problems were created by me in a silly attempt to make an unnecessary modification to the grid's default user interface.  The damn thing would have worked fine if I hadn't insisted on having the select bar just as I wanted it.  Instead, I created many hours of extra work and headaches for myself by trying to fit a square peg in a round hole and make things work exactly as I wanted.  (I realize many decisions like this are forced on programmers by clients or management; in this case I was the only idiot to blame.)

Did having the select bar result in a better user interface than if there had just been a blinking cursor in a single field of the active record?  Yes, there's no doubt about that.  But was that select bar worth all the extra work and extra headaches it caused?  Definitely not.

That Paradox for DOS scenario pops into my head whenever I run across similar situations where a tool provides something that works fine out of the box, but not quite the way I want it.  Of course you always have to weigh the benefits from doing something exactly the way you want against the doing it the way that the tool offers it to you easily.  And you have to have some idea of what doing it the way you want is going to cost in terms of extra time, complexity, etc.  Given the difficulty of knowing beforehand exactly what problems I might run into, I've taken to erring on the side of caution and I usually try to accept what the tool gives me and go from there.  This is the "take what they give you" attitude.

I know that in many cases my program would in fact work a little better or provide a little better user interface if I didn't accept what my tools offer readily.  But I believe that accepting what your tools give you and not trying to make them work exactly like you want can result in (1) huge savings in development time, and (2) reduced complexity of underlying code, fewer bugs, and easier maintenance.  I think these advantages of accepting what your tools readily give you usually justify forgoing the benefit of having the program work exactly as envisioned.

I realize that for this to work you've got to have the right set of tools.  That is, you've got to have a set of tools that by default let you program pretty close to exactly the way you want.  But I really think that fighting off the urge to make things work exactly the way you want is usually beneficial to the success of a project.  It reminds me of the old phrase, "Better is the enemy of good."

I'm curious to hear if other people have similar stories, examples where trying to force tools to do work in a certain way --  instead of taking what the tools readily provided -- caused extra development time and maintenance headaches all out of proportion to the minor gains from making the program work exactly as desired. 

Or whether people think my problems with making things work exactly the way I want may stem from the fact that I'm not good enough at programming.  ;)  I'll readily admit that I'm not the world's greatest programmer, but I really do think that there's a lot to be gained from adopting the attitude I've described, even for good programmers.

Herbert Sitz
Friday, April 4, 2003


Yeah. No arguments with anything you state.

However, there is the scenario of the client or end user who ABSOLUTELY insists upon a feature that just isn't available with the default behavior of the mandated or selected tool, and they won't listen to any argument that indicates that it's a poor use of effort. It sounded like your DOS Paradox selection bar debacle was self imposed. We've all done that to ourselves. Recognition of that makes you a better professional. I've gotten fairly good at avoiding that kind of stupidity myself, but what can you do when it's mandated that you *will* provide that which is not provided out of the box?

And the non programmer manager will say "you whiner, that's what we are paying you to do, not use things as they are, but create new things." And won't accept any opinion that indicates that their stupid feature addition is bloat or non-core to the effort.

To sum up - it happens, and I think you have the perfect attitude, but in the business world, it's hard to do anything useful with that attitude when your end users or clients are undisciplined about requesting nonsensical features with very high cost:payback ratios.

Bored Bystander
Friday, April 4, 2003

Totally agree with you.

Ive had very similar experiences with Filemaker...this is an x-plat dbms designed primarily for the end user.
This means is that it works very well as a RAD type system, so long as you dont fight its pre-designed gui too much.
<g> which of course I do, a lot, because the pre-designed gui has a few annoying limitations.
Im slowly learning though that the best route where its possible is to accept the limitations and work within its rules...cleaner 'code' all around.

Saturday, April 5, 2003

Not putting up with what they give you  is one of the spurs to innovation.  Sometimes that innovation can take too much in the doing or the maintenance of it. 

But without innovation where's the fun?

Simon Lucy
Saturday, April 5, 2003

"The reasonable man adapts himself to the world. The unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." - George Bernard Shaw

That said, I think there's a difference between attempting to make progress, and unnecessarily beating yourself up just to be different. ;)

Brad (
Saturday, April 5, 2003

I find the best strategy is to present a choice. "Sure, we could have this fancy feature, but that would require effort that might better be spent on implementing some other, more important feature. Why don't we get it up and running quickly by writing the simple version first? We can always add the cool features later if we really want them."

I actually realised this while trying to write fiction. I'd write a paragraph, re-read it, cringe and erase it. Never get anywhere doing things that way. Then I realised that I can always fix it in the next draft. Write the story first, then polish the prose.

Angus Glashier
Saturday, April 5, 2003

In 1998 I think it was, I worked on a project which failed considerly. The client paid an awful lot of money for something they couldn't install.

The client wanted a web app doing the impossible. They wanted a rich, highly interactive gui. Their target was customers on different platforms, so they had a legitime reason to say no to a Windows desktop app.

It was ASP 1.0, ADO 1.0, IE has just arrived in sp3, err, version 3, and Microsoft introduced the ActiveX Layout Control which did some CSS-ish positioning.

The final gui looked nice, it actually worked, but needed all data locally to be responsive. Which meant huge scripting files and an unbelievable download time. But the product didn't work in the client's environment, and the technical choices made for making the gui locked us to the Microsoft platform (ActiveX), anyway.

We pushed the technologi towards something it couldn't handle. Instead, we should really have given them an Internet connected desktop app...

Thomas Eyde
Sunday, April 6, 2003

Joel has an anecdote about it in one of the "UI Design for Programmers" chapters. He said something about a company that tried to create a login dialog in Windows that will also behave similar to the UNIX login dialogs, where you have to press enter twice. That caused them to implement a complex logic, and made the code very bad. Since I have to login to both NT and UNIX workstations at school, I noticed that, and I sometimes press enter on the NT. Still, I guess it's not critical that the dialog behaves in a UNIXish way, as long as the username is kept after you press enter.

It's been a long time since I seriously did a UI design of some sort. In any case, I can testify that when working on an open-source C project, I implemented many classes from scratch, because I was not happy with the ANSI C facilities, or to make my project independant of external libraries. The code does not cause me a lot of bugs, but it is nonetheless something I wrote.

I remember implementing a lot of internal logic in Perl that I later found out to be present in the core distribution or in an existing CPAN module. But, then again, the code was relatively short and simple and did its job, so I was able to maintain it. I once implemented a basic SMTP stack in Perl, because wsendmail (a simple command line mail sender for Windows) and other methods I tried did not work. It then turned out to be a bug in the Apache 2 for Win32 Alpha I was using, but I still kept it as it is afterwards, even after I was given an account on IIS where things worked perfectly either way.

Perl is nice that you can re-invent an existing wheel in it, without getting burned down or floded with bugs. It is very nice in this regard.

Shlomi Fish
Sunday, April 6, 2003

Back in the stone age I was Junior developer on an embedded project that had an extremist "just the way I want it" lead architect. It went as far as assembling their own computer for the prototype instead of just bying the thing for peanuts. Result was they spend 6 months on DRAM controller issues and ended up with a functional clone of a 1.000$ commercial part for a development cost of 120.000$. Total production run of the custom part was 3 units. The other 7 instances of the machine delivered went with the commercial part.

Just me (Sir to you)
Monday, April 7, 2003


Shaw is wrong - for example true scientists do not try and fit the universe onto their views but instead try to uncover it the way it is. Plus, all of humans that made it to the Bad Guy's Hall of Fame were unreasonable - at least in my history book that's how it is 8)


You are right, it is important to stick to what the focus of the project is.  IMO we should proof our decisions through Occam's razor to eliminate the unnecessary - ie the KISS principle!


Monday, April 7, 2003

Shaw wasn't talking about scientific discovery, he was talking about invention.

Brad (
Monday, April 7, 2003

"Not putting up with what they give you  is one of the spurs to innovation.  Sometimes that innovation can take too much in the doing or the maintenance of it. 

But without innovation where's the fun? "

I don't think there is a question of whether or not innovation is a good thing, just about how when and why we should do so.

I also don't think there is any question about whether beer is a good thing, but there certainly is no doubt that you should be wise about how (much) when and why you imbibe.

In other words, its not just about picking your battles, its also about picking the right ones to fight.

Robert Moir
Monday, April 7, 2003

Dino -- Yes, the KISS principle may be at the core of all this.  You may create a marginally better program by violating it, but only at the cost of time and expense out of proportion to the gains you receive.  If there's any concern for cost-effectiveness at all -- and when isn't there in a business context? -- then it's almost always best to stick with KISS.

Herbert Sitz
Monday, April 7, 2003

*  Recent Topics

*  Fog Creek Home