Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to hear what kind of design decisions you took and how did they backfire. Because of a bad design decision, I ended up having to support that bad decision forever (I also had a part in it). This made me realize that one single design mistake can haunt you forever. I want to learn from the more experienced people what kind of blunders have they experienced and what did they learn from them.

I'm sure this will be a lot of help to other programmers by helping them to not repeat those decisions.

Thanks for sharing your experience.


locked by World Engineer Jun 6 '13 at 11:05

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by World Engineer Jun 6 '13 at 11:05

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

spending too much time on SO!! ;) – Mitch Wheat Sep 24 '09 at 14:26
@George: seems like your first link is about over-engineering, which can be tangentially related to this thread, but its not a duplicate. The second and last links concern coding errors and management fumbles, neither of which are duplicates of this thread. – Juliet Sep 24 '09 at 14:33
This should probably be made into a community wiki (there's a box when you edit the post). – ilya n. Sep 24 '09 at 14:47
I wish there was a way to vote to counter the close. Downvote a close? – Kieveli Sep 24 '09 at 14:51
What is wrong with all the closed voters? So what if it's not a CW let the asker get some votes for coming up with the question. I'm genuinely interested with this topic. Don't let CW get in the way of good subjective question. Sheesh, SO is full of "CW THIS" screamers. – syaz Sep 24 '09 at 15:03

42 Answers 42

Ignoring YAGNI, again and again ...

True for most, but there are also folks who could use a bit less YAGNI. Neither extreme is the best place to be. – 80x24 console Sep 24 '09 at 21:52

"WIll do it later"
"Later" never comes.

Later never comes. – erikkallen Sep 25 '09 at 8:46
It never does. – Manos Dilaverakis Sep 25 '09 at 8:48
It has been said, If you don't have time to do it right now, what makes you think that you'll have time to fix it later? – Jay Sep 25 '09 at 13:20
We call this "iteration never" – NotMe Sep 30 '09 at 16:34
There is nothing as permanent as a temporary solution. – dietbuddha Jun 4 '11 at 21:40

C++, diamond-shaped multiple virtual inheritance. You get the idea.

I need to create a new account to upvote this again... – Kieveli Sep 24 '09 at 14:53
Yes... painful experiences... – Ed S. Sep 24 '09 at 17:12
I just had an ugly flashback – Neil N Sep 30 '09 at 16:22
@Jay it actually seemed like a good idea at the time. – Alex B Jun 14 '10 at 11:16
I don't know what that even mean, but sounds painful +1 – The Disintegrator Apr 11 '11 at 18:18

Configurability in an application is nice. Too much configurability is a nightmare to use and to maintain.

Yes. True. It's idealism to make everything configurable and tell boss that we'll never need to change a single line of code again. – Jason Oct 9 '09 at 6:40
Having been the unfortunate user stuck with one of those infintely configurable systems for our project management, I can only say, I would upvote you a million times if I could. – HLGEM Jun 3 '11 at 17:11
Overflexibility in configuration is usually because you cannot execute arbitrary code at runtime, so you need to anticipate everything. – user1249 Jun 4 '11 at 21:36
This is called « spoftcoding » as opposed to « hardcoding » – deadalnix Nov 30 '11 at 15:37

From one of my mistakes i've learned that DB normalization shouldn't be followed blindly. You can, and in some situations you MUST flatten your tables.

I ended up managing loads of tables (via models) and performance wasn't as good as it could be with a little flattening for tables.

I could not agree more... I am a software engineer and we are told to always normalize. What a crock of shit. It was only because the teachers havent tried working with truely complex and performance dependent DB's. – The real napster Sep 24 '09 at 14:48
I might add that normalization also can be very positive of course. – The real napster Sep 24 '09 at 14:49
I think programmers are too quick to denormalize for inadequate reasons, but yes, slavish adherence to the rules of normalization is a big mistake. In general, one of my great frustrations in software development is when someone says "We must do X", and when I point out all the problems this will cause, they reply, "That's irrelevant. All the experts agree that X is good, therefore we must do X, always, no exceptions." – Jay Sep 24 '09 at 16:02
My approach to normalization is always straight-forward. I always normalize, BUT if i see a potential performance boost on little flattening - i always test and benchmark and in most cases it pays of to flatten. – Eimantas Sep 24 '09 at 17:24
But normalisation is FUN! :) I'm serious, I enjoy designing data structures. What I would say is that whilst it's easy to de-normalise a normalised schema, the reverse is NOT true. You need to KNOW the rules before you break 'em. – Keith Williams Sep 28 '09 at 12:53

Using a single char in databases for statuses, etc. No point in this at all, the overhead of using a longer char() or nvarchar2() is miniscule compared to the network and parsing incurred by any SQL call, yet the chars always end up rather obfuscated, or running out (not for statuses, but other things). Far better to just put the human readable version in, and to also have in your Java model (in my case) an enum with matching values.

I guess this is a form of premature unnecessary and blind optimisation. As if using a single char will save the world these days. Apart from Y/N booleans in databases that don't support booleans/bits.

+1 Completely relevant to me! – syaz Sep 24 '09 at 14:59
+1 We have just had a meeting on this very issue. We came to the same conclusion. – APC Sep 25 '09 at 6:39
What if your customer works with such abbreviations and doesn't want to abandon them? – Scoregraphic Sep 25 '09 at 7:55
For existing systems you need to be compatible (I'd still create a Java enum of proper values, with a <code>MyEnum fromChar(char c)</code> method) of course. For new designs, just don't go there! – JeeBee Sep 25 '09 at 11:49
Almost as bad: Using the BIT type in MS SQL Server, before discovering that it cannot be part of an index. – finnw Oct 1 '09 at 13:39

Not developing a proper Data Access Layer, and having sql everywhere in my code, just to get something "quick" up and running. Later on, as the project started to expand, and requirements changed, it became a nightmare. I didn't know what a DAL was at the time.

... glad I'm past that, although I still see programmers with 20+ years of "experience" doing this.

Can't remember where I read it, but there's a difference between 20 years of experience, and one year of experience repeated 19 times. – CaffGeek Oct 6 '09 at 16:40
@Chad: It was somewhere in the Joel Spolsky's writings. – user8685 Jun 4 '11 at 21:25
+1: Yup. And try refactoring all of that logic tied up in that SQL... Whether it's inline, free-form SQL or stored procs. [Yup - I'm not afraid of that holy war.] – Jim G. Jun 5 '11 at 1:10

Thinking I could be Architect, Developer and PM all on the same project.

2 months of sleeping 3 hours a night taught me you just can't do it.

So stop sleeping so much! oh, wait... you mean thats NOT normal...?? Hmm, I gotta get me some other people on this project... – AviD Sep 25 '09 at 7:54
Sounds like the PM-you need some training with estimates :) – user1249 Jun 4 '11 at 21:37

Chosing Microsoft Foundation Classes (MFC) for writing a Java IDE.

Owwww. That would make my brain hurt. – Greg D Sep 24 '09 at 14:40
That was not a bad decision in 1999. AWT was ugly and slow then. – finnw Oct 1 '09 at 13:45
finnw - well, atleast it is still ugly! – Niklas H Jun 4 '11 at 22:17

It wasn't my decision (I joined the company somewhat later) but somewhere I worked took i18n a bit too far, including translating all their log messages.


  • More painful to add new logging
  • More cost for translation
  • Logs are harder to read afterwards


I'm doing some i18n here, and trying to figure out what goes to the user and what goes into the logs. I want all user-facing output localizable, but I want the logs to remain the same. In the process, I'm having to do more figuring out of where an exception goes than I like. – David Thornley Sep 24 '09 at 14:59
Let me guess, your American? And if not, you only speak english? Use internationalisation where new log entries in english, if another language is available you display the users language. HINT: Using error codes helps here as it means you can always grep/scan logs no matter what the language. – Jacob Sep 25 '09 at 10:11
@Jacob: I'm English, but only speak English. But this was for a company where the entire engineering base was in England, so having log files (which are for diagnostic purposes, not user visible information) in other languages would just be a waste of resources. I agree that using error codes instead of text allows on-the-fly translation - but it's still more work than just using a single language to start with. It's a matter of reducing work by identifying where something that sounds useful is actually not going to provide any significant value. – Jon Skeet Sep 25 '09 at 10:20
I'm Swedish. I would have to get medieval on anyone that even suggests that code/comments/logs should be in anything else than English. English is THE language to use for everything but user interfaces. Everything else just makes code hard to read and discuss. Using a native language is ridiculous since any other framework/library you use is in English. – jgauffin Apr 8 '11 at 8:20
+1 English is the lingua franca of programming. Having it translated is just putting in an additional layer where you need as few layers and as much clarity as possible. – user1249 Jun 4 '11 at 21:38

Reinventing the Wheel


Doing too much design. Creating lots of UML diagrams, particularly Sequence diagrams for every single operation, much of which in the end turned out useless. At the end it turned out that significant amount of time could have saved by skipping unnecessarily detailed design/diagrams and starting coding directly.

If the question was, "What is the most regrettable design or programming decision you have ever seen made?" as opposed to mistakes we'd made ourselves, I'd put "UML" near the top of my list. Right below "the Windows registry". – Jay Sep 25 '09 at 13:24
UML is good to discuss between members of a team, but when it comes to the design then implement according to the design, it always ends up badly. This is some kind of a dream of some companies, but trully, software writting definitively don't work that way. +1 ! – deadalnix Jun 4 '11 at 21:35

Believing customers know what they want and then doing too much before checking with them.


My single worst design decision? Back in the 1980's I was working on a project where we got the bright idea to create a kind of template for our data entry screens which would be interpreted at run-time. Not a bad decision: it made input screens easy to design. Basically just create a file that resembled the data entry screen, with some special codes to identify what was a label vs what was an input field, and to identify whether input fields were alpha or numeric. Then I decided to add some more special codes to these files to identify what validations should be performed. Then I added more codes to allow conditional building of the screen, field X only included when some condition was true, etc. Then I added more codes to do some simple processing of the inputs. Etc. Etc. Eventually we had turned our screen template into a new programming language, complete with expressions, control structures, and an i/o library. And what for? We did a ton of work to re-invent FORTRAN. We had a shelf full of compilers for languages that were better designed and better tested. If we'd devoted that much effort to building products where we actually had some expertise, that company might still be in business today.

That's both funny and tragic :) – cwap Sep 25 '09 at 7:01
The sad thing is that this approach is sometimes the best way to go. The customer can pick either "screen can be changed at a moment's notice" or "screen does everything including make the tea" but not both! – Christian Hayter Sep 25 '09 at 8:05
I have nothing against using templates or other generic code. The mistake was in turning a piece of generic code into a language-within-a-language. – Jay Sep 25 '09 at 13:54
I have seen this exact thing 2004! All the business logic is spread over around fifteen configuration tables with several half baked attempts at dynamic "languages" thrown in for good measure (see Greenspun's Tenth Rule)! – Internet man Sep 28 '09 at 7:46
Don't you mean COBOL rather than FORTRAN? – finnw Oct 1 '09 at 13:50

Over-zealous application of YAGNI (which is termed Design by Enumeration in Pitfalls of Object Oriented Development) in an environment where any sensible person could tell that the requirements were definitely going to change. And change repeatedly.

If you've (hard-)coded everything exactly to the current requirements—while beating down anyone who says "couldn't this be more generic?" with your YAGNI mallet—and then the requirements change drastically (but in a way that could have been reasonably anticipated), then that can be the difference between taking 2 weeks to adapt, vs. taking 20 minutes.

UPDATE: To clarify, here's a fictitious example that's not too far from what happened. Stack Overflow was designed to support badges, but suppose they could only think of four badges at first. Only four, such a small number, so they hardcoded support for exactly four badges throughout all of the logic in the site. In the database, in the user info, in all the display code. Because "Ya ain't gonna need" any badges that you can't think of, right? Suppose then that the site goes live, and people start suggesting new badges. Each badge takes up to two weeks to add, because there's so much hardcoding to tweak all over the place. But still, "Ya ain't gonna need" any more badges than today's list, so there's never any refactoring to support a generic collection of badges. Would a such a generic collection have taken any more time up front? Not much, if any.

YAGNI is a valuable principle, but it should not be (ab)used to excuse poor design and inappropriate hardcoding. There's a balance, and with experience, I believe I'm approaching it.

Yes and no, can you predict in what direction it's going to change? I have experience of painfully complex systems which proved totally inadequate for the first reuse, which didn't fit into the predicted genericity... – Benjol Sep 25 '09 at 9:56
^yep, I'd rather deal with YAGNI than that crap. – Fred Sep 25 '09 at 15:25
So you think you should have spent the 2 weeks upfront? – finnw Oct 1 '09 at 13:58
That example is not YAGNI at all. DRY is part of YAGNI, and without it you cannot stay responsive to change. – Stephan Eggermont Jan 18 '10 at 19:56
Stephan, the example shows a glib and inappropriate abuse of the catch-phrase, which was my point. DRY (with its variant OAOO) is also a good principle, but quite separate: However, I cannot find anything anywhere to support your claim that "DRY is a part of YAGNI." Mustard goes well with hotdogs, but that doesn't mean mustard is a part of hotdogs. If you could clarify, perhaps with references, perhaps I will understand. – 80x24 console Jan 22 '10 at 21:51

Incompetent human resources

Trying to make something right and great with wrong people!
Even if they're in the role of a superfluous ego PM (which is rather too common especially in big firms where their incompetency can endure for a longer time).

I understand your pain :( – user7197 Jun 4 '11 at 20:01

Every single time I create technical debt, write procedural code, skip writing tests, etc. because I'm rushing. Almost inevitably I find this creates pain for me down the road.


Using SQL Server Intergration Services (SSIS).

I dont wish it on my worst enemy.

After building several SSIS packages over the past two months, only to come to find out that the packages I developed are not distributable & and undeployable. Specifically in a non-web, non SQL Server licensed environment.

It's a very bad situation to be in, when you have less than 48 hours to re-write your SSIS packages in pure .NET POCO code or miss your targeted deadline.

It amazes me that I was able to rewrite three SSIS packages (that took me two months to test and develop), within 12 hours in pure .NET code, with OLEDB Adapters and SQL Adapaters.

SSIS is not distributable and will not execute packages from a client machine if it does not have a SQL Server license installed on it (Specifically the DTSPipeline.dll). This would be great to know up front. I do see the disclaimer now (in fine print) on MSDN. That does no good when you have example code all over the internet using SQL-LICENSED machine only code. Basically, you have to create a web service that will talk to your SQL server, to run your SSIS packages programmatically. You cannot execute them from pure .NET code, unless you do have a SQL license installed on the executing machine. How unrealistic is that? Does Microsoft really expect SSIS to be used from machines that require SQL server installation? What a complete waste of two months.

My company will never again use SSIS because of this small print "gotcha".

Perhaps you should avoid using "fine-print" software altogether! Talend for example is an open-source ETL IDE. – Joe Koberg Jan 22 '10 at 22:21
+1: Yup. The SSIS development experience is a nightmare too. There are probably at least a half-dozen better ways to perform ETL. – Jim G. Jun 5 '11 at 1:13

Not defining the deployment mechanism/model as early as possible.


Throwing in some 'funny' easter eggs into some code I wrote before going on vacation for 2 weeks. I thought I'd be the only person to read it when I got back, it'd get me chuckling and ready to re-code it.

Needless to say, my boss wasn't impressed when he reviewed it while I was away, and he was even less impressed when one of the 'easter eggs' was involving his face funnily cartooned in ASCII.


IMO, that's "Good work Sir!" – JeeBee Sep 24 '09 at 14:45
Very recently, I was mocked by my team for trace messages like, "addin' th'value (p) t'yer table!" I said look, they made me work on Talk Like A Pirate Day, they deserve what they get. – catfood Sep 24 '09 at 14:47
Arr, your loggs be lookin' for a keel'haulin! – Robert P Sep 24 '09 at 23:29

Using ASP.Net Themes when just a regular ol' CSS folder would've done just fine.

Lol at that, yes! – Jacob Sep 25 '09 at 10:17
This answer could be shortened to "Using ASP.NET" – finnw Oct 1 '09 at 13:51
Skins are useful for setting up the default CssClass. – Min Oct 1 '09 at 16:55

Taking the quick road to getting some code working, rather than the right road (bit general, but we'll call it an abstraction and therefore a 'right' answer).


My company has a waterfall-like development model, where our business users and business analysts will define requirements for projects. On one of our "big" projects, we got a stack of requirements, and I noticed a number of requirements contained implementation details, specifically information related to our database schema used by our accounting system.

I commented to the business users that implementation is my domain, it shouldn't be contained in the requirements. They were unwilling to change their requirements because, after all, they are THE BUSINESS, and it only makes sense for accountants to design accounting software. As a lowly developer who is too far down the totem poll, I'm paid to do instead of think. As much as I fought it, I couldn't persuade them to re-write the requirements -- there is too much paperwork and red tape around changes that its just too much of a hassle.

So, I gave them what they asked for. At the very least, it sorta works, but the database is weirdly designed:

  • Lots of unnecessary normalization. A single record containing 5 or 10 fields is split across 3 or 4 tables. I can deal with that, but I'd personally like to have all 1:1 fields pulled into a single table.

  • Lots of inappropriate denormalization. We have a table which stores invoice data which stores more than invoice data. We store a number of miscellaneous flags in the InvoiceData table, even if the flag isn't logically related to the InvoiceData table, such that each flag has a magic, hardcoded Primary Key value and all other fields nulled out in the InvoiceData table. Since the flag is represented as a record in the table, I suggested pulling the flag into its own table.

  • Lots more inappropriate denormalization. Certain app-wide flags are stored as columns in inappropriate tables, such that changing an app's flag requires updating every record in the table.

  • Primary keys contain metadata, such that if a varchar primary key ends with "D", we calculate invoices using one set of values, otherwise we calculate it with another set. It would make more sense to pull this metadata into a separate column, or pull the set of values to calculate into another table.

  • Foreign keys often go to more than one table, such that a foreign key ending with "M" might link to our mortage accounts table, whereas a foreign key ending with "A" might link to our auto accounts table. It would be easier to split the data into two tables, MortageData and AutoInsuranceData.

All of my suggestions were shot down with much wailing and gnashing of teeth. The app works as-designed, and while its a big ball of mud, all of the nasty hacks, special cases, and weird business rules are sarcastically and humorously documented in the source code.

Goodness, hope your CV is nice and up to date for a quick escape before the big ball of mud succumbs to gravity! – Benjol Sep 25 '09 at 9:58

Sticking to older technology because it seems too much hassle to let your clients upgrade to a new .NET framework version, but it actually will take more development time to create the software because you can't utilize some (time-saving) components of the newer framework version.

+1: Yup - I've been there... And as soon as I realized that the n00bs wouldn't upgrade, I began to plan my escape to greener pastures. – Jim G. Jun 5 '11 at 1:07
And so I did, just retired the next month! – vines Jun 5 '11 at 21:33

Back in the university I was working on my senior design project. Another guy and I were writing a web-based bug tracking system. (Nothing groundbreaking, but we both wanted to get some web experience.) We did the thing with Java servlets, and it worked reasonably well, but for some silly reason, instead of opting to use Exceptions as our error-handling mechanism, we chose to use error codes.

When we presented our project for a grade and one of the faculty asked the inevitable, "If you had to do it again, what would you do differently?" I instantly knew the answer: "I'd use exceptions, that's what they're there for."

Ahhh the joys of reinventing the wheel! :-) That's funny. – jaredmdobson Sep 24 '09 at 15:18
I call it intentional flaws, just so that you can improve it in the next iteration. – whatnick Sep 24 '09 at 18:42
Exceptions are for handling exceptions only. Too many people abuse exceptions by turning everything into an exception. – Jacob Sep 25 '09 at 10:12
@jacob - I agree with your sentiment that exceptions should be used for things that you can predict (ie exceptional conditions) but from what I have seen (and not being a Java programmer) Java seems to use exceptions for everything under the sun. So not using exceptions in Java code could be considered going against the flow of the language. – Peter M Sep 25 '09 at 14:08

Not my choice of method, but created an XSLT to convert a row based XML file into a column based HTML report.

It only worked in IE, was completely impossible to decode how it worked. Everytime we needed to expand it, was impossibly difficult and took ages.

In the end, I replaced by a tiny C# script which did the same thing.

I've done that too. I implemented an email templating engine using XSL and found it difficult to read and maintain. – TrueWill Sep 24 '09 at 17:13
Yep. Replaced someone's huge tree of XSLT files with a few simple VB.NET functions. Very satisfying, especially when the next customer change request that came along would have been impossible to do in XSLT. – Christian Hayter Sep 25 '09 at 8:22
I've found that most programmers consider XSLT a bad choice, simply because they dont get it. Its extremely useful for a small set of problems, much more efficient than many other solutions. On the other hand, it is used WAY too often, and mostly NOT in that small set of problems... – AviD Sep 25 '09 at 14:35

trying to use all the new technologies (to learn new technology) even though it doent even require..


I didn't take enough time to assess the business model. I did what the client asked, but 6-12 months later we both came to the conclusion it should've done differently.


Designing without a specification.

Specs arent always possible – Jacob Sep 25 '09 at 10:15
Should be "Implementing the solution without asking the customer if that's what they wanted"; which usually means you followed the specs. – dietbuddha Jun 4 '11 at 21:36

I implemented a sub-section of an application according to the requirements.

It turns out that the requirements were bloated and gold-plated, and my code was over-designed. I should have designed my sub-section to only work with what I was adding at the time, but plan for adding all the other stuff without including generic support for it from the outset.