I find the article to be in line with my recent rants at work.
My background is airline and finance enterprise software where lots of highly skilled of people are paid a high salary to do relatively simple and small coding tasks. (That's what they think but in reality most just don't want to take the initiative to go beyond the status quo, but that is another rant altogether).
More often than not this leads to engineers taking every opportunity to over-engineer a solution to simple problem so they feel that they are seen as top-notch engineers when in effect they are taking a simple problem and turning it into a maintenance and support nightmare.
In these situations a simple change such as adding a field to a method signature impacts multiple classes and interfaces due to the Lasagna code effect.
In this environment engineers religiously spend additional time planning, designing, and coding their solutions to be adaptable to changes that have almost no chance of happening.
If you spend 4 days creating an IT system that can seamlessly switch between and active directory back-end and a RDMBS (or anything unforeseen for that matter) back-end but the change never happens, then you just wasted 4 days. If instead you waited until the RDBMS support requirement was necessary it would probably still take the same 4 days but they would not have been wasted.
On the other hand, I am now looking at a system that has been fast-track maintained for multiple years, to the point that a simple change now takes multiple days of puzzling over mysterious side effects. I can't even begin refactoring it. I don't know where to start. It's a tightly interwoven ball of 'interesting' decisions, patches, changes and obsolete requirements. The fact that all the original developers no longer work in this place is additional bonus. The only plausible solution seems to collect the current business needs and rewrite the damn thing.
On the other hand, it's an opportunity to rewrite the custom system into a product. Clients have shown interest in having their own copy multiple times, but the cost of implementing that horrorshow on their systems has always been a prohibiting issue.
It sounds like most custom IT business solutions. This brings to light something I have been pondering for a while now.
Basically, there are two types cultures related to development teams.
Culture A, treats the software as their business and respect it as much as they do their customers, employees and partners.
In an "A" department developers are empowered to take ownership over the code. This means that they feel obliged to refactor
code and improve comments, documentation, and tests as a part of of whatever change they are delivering.
It is understood that bugs can come from this but that the overall benefit of not ending up with an unmaintainable system
is worth the cost of an accidental bug from time-to-time.
Culture B, treats the software as a necessary evil or at best a commodity. Developers are instructed to perform the least amount
of changes to meet the changing business requirements. These department are almost always in crises mode as the inflexibility of there
bubblegum patchwork has put them into a reactionary relationship with the team who is driving the requirements.
In "B" departments you often see high turnover by the best engineers since they feel something is wrong with the departmental management strategy.
The high turnover in turn leads to less knowledge about the most complex components in the system and even more reluctance from the management
and engineers to risk refactoring something that no one completely understands.
I've noticed the "B" shops are always looking for a new silver bullet, the new servers to be able to run the integration tests in under 48
hours since the code is not unit testable or changing frameworks every two years in hopes it will lead to a more flexible system.
Unfortunately, in my experience, the "B" companies tend to pay the highest salaries.
My background is airline and finance enterprise software where lots of highly skilled of people are paid a high salary to do relatively simple and small coding tasks. (That's what they think but in reality most just don't want to take the initiative to go beyond the status quo, but that is another rant altogether).
More often than not this leads to engineers taking every opportunity to over-engineer a solution to simple problem so they feel that they are seen as top-notch engineers when in effect they are taking a simple problem and turning it into a maintenance and support nightmare.
In these situations a simple change such as adding a field to a method signature impacts multiple classes and interfaces due to the Lasagna code effect.
In this environment engineers religiously spend additional time planning, designing, and coding their solutions to be adaptable to changes that have almost no chance of happening.
If you spend 4 days creating an IT system that can seamlessly switch between and active directory back-end and a RDMBS (or anything unforeseen for that matter) back-end but the change never happens, then you just wasted 4 days. If instead you waited until the RDBMS support requirement was necessary it would probably still take the same 4 days but they would not have been wasted.