Code > DataModel

When developers are more focused on macro-intricacies of their code VS retaining the integrity of the data model.

IE: when you’re code is building relationships to form data models VS the data models being normalized entities that I identify their relationships using primary identifiers.

Most of the time, this is a result of the “Second System” effect where you need to prove your ninja status by producing the most robust backend operations that utilize every design pattern that the gang-of-four called out.

My view: You can always re-factor and redesign shitty code, it’s not so easy to roll back transactions after your data model is corrupted and/or fragmented.

DataModel > Code

Presentation > To customer/user VS mutli-threaded com apartments using a polymorhphic factory pattern.

Early web browsers had to parse HTML and present it reasonably. Modern browsers must present HTML precisely, support XML, support XSLT, support a lexer/parser and (fast) compiler for javascript, a DOM object model, a plugin infrastruture, CSS, SSL, SVG, embedded Java, Flash, O3D.

C++ supports ‘generics’, generics let you define a data structure once, and then make multiple versions of it for different payload types. You write a generic linked list, and instantiate it to carry INTS, another for carrying CHARACTERS, and another for carrying a user defined structure. You end up with 3x the object code, but it is typesafe. This was done in C by using void* (a pointer to an object of unknown type) as the datatype — a solution which needs 0 new lines of code.

Programming languages are conventionally a lexer (to turn TEXT into tokens), parser (to turn TOKENS into AST [abstract syntax tree]) and compiler (to optimize the AST and produce COMPUTER INSTRUCTIONS). An alternative is to just write a text -> AST translation, which can be done easily if the language is not complicated (i.e. PREFIX: (+ 1 4 3) or POSTFIX: 1 4 + 3 +, but not INFIX: 1 + 4 + 3)

For example, it’s just wrong to build a monolithic application instead of a collection of single, focused applications. We’ve proved this over and over for almost 40 years now in software development–it’s time that people just took the obvious proof and stopped designing systems to “do everything”.

Once we get down to the single, focused application, that’s where under-engineering (or as you correctly put it, under-designing) gets into play too often. When you’re designing a focused application, you can actually be a lot more flexible than people think about. In fact, the smaller your focus is, the more flexible you can be. For example, if you break things out into libraries, then you can really focus on the quality of the library as though it was a library that anybody was going to use.

For example, I just wrote Parse::StackTrace–a library that I needed for actually only one purpose, but I wrote it as though lots of other people were going to use it–I gave it a full test suite, a complete API, etc. As a result, it was a lot easier for me to use, too!

Anyhow, I could go on and on about this, but that’s the basics.

-Max

Well, my point here is, I couldn’t figure out a hardcore rule to categorize a system as over designed or under designed. If you have some guidelines to classy software systems so, pls let us know.

-Max

I got a deliverable in a research project asking me to make sure I avoid over-engineering in the project. Whilst I worked as programmer before and am totally with you on the way you discussed the topic above, thinking about it: Does over-engineering not go much further than just writing complicated code rather than a few lines which would do the job. Doesnt it start already on a mangement level? Is it not over-engineering in software projects in general if I for instance impose processes and reguluations (such as Unit tests) for all possible cases even if it might not be necessary?

If anyone has any ideas or hints to literature that be great!!

Christine

-Max

Say that you need to reverse a string in ONE place in your code, and to make it reusable you decide to make a function:

function string_reverse(string)
{
// reverse the string
// return the reversed string
}

somestring = string_reverse(somestring)

While you are coding this, you think to yourself “wouldn’t it be AWESOME if this could handle a whole array of strings and process each of them? that COULD come in handy SOMETIME”, so you code:

function string_reverse(string)
{
// if this is an array of STRINGS, loop through it:
// {
// –> reverse the string in the current element
// –> add the reversed string back to the array
// –> return the reversed array once the loop is complete
// }
// else (this is a string)
// {
// –> reverse the string
// –> return the reversed string
// }
}

somestring = string_reverse(somestring)

Notice the ONLY thing that changed here? You just wrote a bunch of completely useless lines, and you STILL ended up with a function that did just one thing for YOU, reversing that ONE string you have.

That’s why less overengineering is more productivity, because you spent X minutes coding something you don’t need now, and could have JUST AS EASILY added the array handling LATER if you ever needed it, but instead you wasted time coding features into a function you A) only used once on your code and B) only ever NEED it to handle strings for the forseeable future.

I think this is a prime example of real-world overengineering.