Overdesigning your software up to the point it can’t be built

and every single dinky little class that you need to split a URL into four parts becomes an engineering project worthy of making a bridge (Joel Spolsky, StackOverflow podcast 38).

Developers love to write software, but there's something some developers (and software architects) loves even more – to design software – and if you can skip designing something specific (that might actually be useful) and create some over-reaching principle for the design of every conceivable piece of software it’s even better.

Now, when you leave practical considerations behind and head for the principles things tend to go bad, for an example take a look at this blog post, it’s a story about all the work you have to do to make the simplest most trivial “domain model” in a way that doesn’t ever let bad data into the model.

The writer of the post very skillfully got the model to the point it could never, even in theory, accept bad data, that required quite a bit of code, a lot of testing and changes that made the code incompatible with most persistence frameworks (persistence frameworks are libraries that can automatically save and load objects to and from databases, like Hibernate/NHibernate, Microsoft’s Entity Framework and many others).

Now, if we try to take a practical look at this code, I’m not even sure it’s possible to write large scale software like that, but more importantly those “models” are almost always stored in a database, every database can easily enforce the constraints described in this post - so, even if the user manages to get the model into an invalid state – that state could never be saved into the database, meaning the program will either let the user correct the bad data or crush – exactly the same result as the approach described in that post.

I’m not trying to criticize the author of that post, the post purpose is after all to show us that writing such no-compromise code is harder than you think – I just have a radically different conclusion than the author, that you shouldn’t do thing the hard way if there isn’t a practical real world advantage that effects the end product.

There is no shortage of examples like that on the web, I only picked that one because it came up in a completely unrelated Google search.

If you want to make software development easier, first make software not “principles” or “best practices” – what’s right for one project probably isn’t such a great idea for another project - and whatever you do, don’t use any design methodology or architecture that makes your work more difficult without some real world advantages.