5 ms·

One of the ways ive seen these systems born is when the user requirements are ill-defined. "Okay so you are not sure - you may need either foo or bar, so we wi

One of the ways ive seen these systems born is when the user requirements are ill-defined. "Okay so you are not sure - you may need either foo or bar, so we will put this little foo-to-bar knob here so you can tune it just as you like, however you like, whenever you like". Neither of the parties involved in the project definition can be bothered to figure out what actually has to be done, and next thing you know you end up with an overpriced-overengineered specialized turing complete language interpreter that has the customer do all the actual work implementing the business logic. My theory is that this often stems from a communication issue. And some laziness.

gommm 15y ago
And it's fun for novice programers to implement this kind of overenginered specialized turing complete language... Until one has been burned by one, it's very easy to be lost in overarchitecturing and be very happy with one's own cleverness. When I look back at the projects I started, way back when I started programing, they all tended to have this characteristic and were completely unmaintainable (which is why they were never finished)
- michaelfeathers 15y ago
  I've seen a very bad case of this that was a direct result of the 'second system effect'. The devs were told that they could have a re-write, but it would be the last re-write, so everything became configurable.
- mhw 15y ago
  And I spent quite a bit of my early years as a team lead dragging novice programmers back off the slippery slope of the configuration system. You can tell someone's edging out onto the slippery slope when they extract things out of the source code and into a configuration file. Then they realise they need to expose values from the runtime environment into the configuration file, so you get symbolic values added to the language. From there it's a short slide to implement expression evaluation and conditionals (one usually comes before the other, but they fit together so well that I've never seen someone fail to implement both 'to cover future scenarios'). A lot of configuration systems reach a complexity maximum at this point, where the ability of the implementor (or their memory of the compiler construction class) runs out before their ambition for their configuration language does. Some particularly resourceful individuals press ahead regardless though and find a way out of this sticking point. At this point they will often also separate their configuration system out into a library so that others can gain the benefits of a poorly thought-out programming language being embedded directly into their software. For some companies, the configuration library would be the only reusable component shared between different applications because the guy who wrote it was the one everyone else looked up to. The other route out of this sticking point came through the trendiness of XML and the availability of general purpose XML parsers. This meant that not knowing how to build a proper parser (with decent error messages and such like) was no longer an obstacle, just as long as you could convince people that writing programs as XML elements was a step forward. XML parsers also turned your configuration file into something similar to an AST (if you made your language look like a serialized AST) so programmers who had never even done the compiler course could stumble across the solution without too much effort. At least configuration files could be checked into some source control system and managed properly. Don't get me started on storing business rules in relational databases...
tsewlliw 15y ago
This is exactly why I prefer tools that take a stance on what the right way to do something is. Even if I don't like some aspect, I at least have a little confidence the author thought hard about a corner case and made a well considered decision. At DevDays in Austin a couple years ago Joel Spolsky complained that at Freebirds ordering a burrito consists of telling them the recipe for a burrito. I've got work to do, I don't want to tell my tools how to make a burrito.
- jiggy2011 15y ago
  The problem is a developer is not always in a position to make the decisions on what the right way to do things are. In order for a developer to understand the requirements of the software he requires a deep understanding of how the business works, which is probably at least as deep a the person specifying the software or managing the developer. Even if the developer has a better understanding that the manager about what is required he may still have rank pulled on him by the manager. A developer who understands the business well enough to write good software for it probably understands the business well enough to run it which makes the manager superfluous anyway.

gommm 15y ago

And it's fun for novice programers to implement this kind of overenginered specialized turing complete language... Until one has been burned by one, it's very easy to be lost in overarchitecturing and be very happy with one's own cleverness. When I look back at the projects I started, way back when I started programing, they all tended to have this characteristic and were completely unmaintainable (which is why they were never finished)

michaelfeathers 15y ago
I've seen a very bad case of this that was a direct result of the 'second system effect'. The devs were told that they could have a re-write, but it would be the last re-write, so everything became configurable.
mhw 15y ago
And I spent quite a bit of my early years as a team lead dragging novice programmers back off the slippery slope of the configuration system. You can tell someone's edging out onto the slippery slope when they extract things out of the source code and into a configuration file. Then they realise they need to expose values from the runtime environment into the configuration file, so you get symbolic values added to the language. From there it's a short slide to implement expression evaluation and conditionals (one usually comes before the other, but they fit together so well that I've never seen someone fail to implement both 'to cover future scenarios'). A lot of configuration systems reach a complexity maximum at this point, where the ability of the implementor (or their memory of the compiler construction class) runs out before their ambition for their configuration language does. Some particularly resourceful individuals press ahead regardless though and find a way out of this sticking point. At this point they will often also separate their configuration system out into a library so that others can gain the benefits of a poorly thought-out programming language being embedded directly into their software. For some companies, the configuration library would be the only reusable component shared between different applications because the guy who wrote it was the one everyone else looked up to. The other route out of this sticking point came through the trendiness of XML and the availability of general purpose XML parsers. This meant that not knowing how to build a proper parser (with decent error messages and such like) was no longer an obstacle, just as long as you could convince people that writing programs as XML elements was a step forward. XML parsers also turned your configuration file into something similar to an AST (if you made your language look like a serialized AST) so programmers who had never even done the compiler course could stumble across the solution without too much effort. At least configuration files could be checked into some source control system and managed properly. Don't get me started on storing business rules in relational databases...

tsewlliw 15y ago

This is exactly why I prefer tools that take a stance on what the right way to do something is. Even if I don't like some aspect, I at least have a little confidence the author thought hard about a corner case and made a well considered decision. At DevDays in Austin a couple years ago Joel Spolsky complained that at Freebirds ordering a burrito consists of telling them the recipe for a burrito. I've got work to do, I don't want to tell my tools how to make a burrito.

jiggy2011 15y ago
The problem is a developer is not always in a position to make the decisions on what the right way to do things are. In order for a developer to understand the requirements of the software he requires a deep understanding of how the business works, which is probably at least as deep a the person specifying the software or managing the developer. Even if the developer has a better understanding that the manager about what is required he may still have rank pulled on him by the manager. A developer who understands the business well enough to write good software for it probably understands the business well enough to run it which makes the manager superfluous anyway.