I don't particularly respect Fowler as a whizz or an authority. To me he's just another programmer sharing observations and opinions. Though unlike me, he appears to have ultimately devoted more of his career to writing about programming. I'm not someone that particularly pays attention to his writings. I don't know what his code is like and I've only seen bits and pieces of his work. I can't say what I've seen is terrible but it is a single perspective and one person's set of opinions.
I do however intimately know about the impact of his writings in scenarios relevant to what Fowler and those of his cohorts who follow the same philosophy propose here. I've had to inherit many a codebase "architected" by those who follow Fowler and have been given enough time or in this case rope to hang themselves. Whenever I see a monstrosity of a bloated OOP mess, a nightmare, there's a Fowler, a Gang of Four or similar book nearby. There are certain books that if you see them, they're a bad code smell, you can make a guess that the codebase is in a terrible state and you'll be right nine times out of ten. It'll be a specific kind of mess which might take many forms but inevitable comprises tangled layer upon layer of assorted abstractions. It's not that everything in these books is necessarily bad, it's a mix, though I'm not sure if the authors understand their audience, their audience's limitations and if it's even possible for any book to produce a positive effect.
The problem is that people such as Fowler, whether intentional or not, create resources that lend exceptionally well to facilitating process driven blind programming that doesn't actually produce quality software. Fowler is a master of prescribing rituals that people who like to follow rituals can easily adopt.
I can attest that in my experience writing code properly does result in greater productivity despite an initial lag as it has a much higher ceiling. The net result between the two can easily be an order of magnitude, sometimes exponential. Better code really does cost less. I've seen bad code now costing easily hundreds of thousands to millions over the course of a few years on programmers salaries alone. However, following Fowler has virtually no relevant bearing on whether code will be better or not. Nor will assessing whether code is "better" or not according to criteria that might be set out by Fowler either directly or indirectly be all that useful in ascertaining quality level. It's more likely to quickly depress software quality as people rush to implement things that aren't needed so to check all the boxes.
Conversely people that follow Fowler and his crowd tend to make things much much worse when given more time. Fowler provides a lot of things people can waste time doing. More time means more layers of indirection and code for the sake of code. Virtually all of said additions incur a guaranteed cost and non of them provide guaranteed benefit. I'd like to hope that Fowler is aware of this and cautious in his approach, though his advice here has plenty of potential to be a plea to provide budget for this kind of waste which is counter productive.
I might have a backlog like this...
* Users->Feature: Allow users to have more than one X.
* Government Agency->Compliance: Update data collection to include field X.
* QA->Lifecycle: Make mission critical area X is easier to test.
* Audit->Research: Investigate ways of detecting fake users.
* Research->System: Upgrade database to next major version to gain feature X.
* Benchmarks->Optimisation: Use precise indexes for use case X.
* Business->Feature: Allow billing on an annual basis.
While performing these, you might use a variety of different strategies and approaches as a side effect. Refactoring tasks might spawn from them.
A back log inspired by Fowler and friends might look like this:
* Fowler->Code Quality: Implement Specification Pattern.
* Blog->Code Quality: Implement Command Bus.
* CS 134->Code Quality: Implement Unit Testing.
* Conference->Code Quality: Implement Event Sourcing.
* Job Specs->Code Quality: Implement DDD.
* Social Chat->Code Quality: Implement Visitor Pattern.
* Best Practices->Code Quality: Implement REST fully.
When a Foullower is performing these, they might implement some features as a side effect. Code Quality (tm) tasks might spawn from them.
If you write a back log such as the one I originally wrote, don't expect it to solve the problem. All of the items from above will be aliased to those below, most likely respectively.
The code produced by such a follower of Fowler will present you with a riddle, wrapped in an enigma, housed in a mystery, planted in a puzzle, kept in a secret and all tied up into a knot. It might as well actually be encoded which often ironically arises from people following blind processes for the promise of readability.
I very commonly see code that only has to take a simple list from the database and return it to a client in a format such as JSON. If I implement this feature then I end up with very little code. Perhaps a dozen lines. If more than one object or method, almost certainly not exceeding half a dozen. We're probably talking around 50 lines, though do it a second time and that can drop to 10 lines. When it's code following rituals Fowler sets out, you can expect portions of it to be dispersed all through out the system. Dozens of hops, classes, methods, hundreds or even thousands of lines, etc. You'll probably find those things ill construed as ultimately effort will have been divided across such a system. It boggles the mind when people do things like convert a map to an object, send it through a maze then convert it back to a map again only to run a few if statements on a few fields and to rename or cast a few fields.
You can't entirely blame Fowler for this stuff, people can take his stuff and do what they want with it or leave it but you also might think he'd be more aware of this set of problems arising from process driven and fad driven development. Not many people are going to like this but the truth not many people building software know anything about building software either and Fowler isn't particularly effective at improving that despite his efforts. Fowler exploring other shops is good, there's a lot of variety and things to see in software engineering, though I think he needs to see more environments, where he'll surely see that more time than really needed is catastrophic. Though it might not be obvious unless actually working on such a codebase and realising half of it can be tossed. Give away time and money don't expect it to be spent wisely by default. Some programmers will do amazingly but most will squander it. You'll end up with Albanian bunkers.
I think there's also a cultural different. Many people including Fowler talk as if they've been spoiled in certain regards. It would be nice if that were the situation for all programming but the reality is, in the professional world that's by far not normal. Many programmers for not have financial security. Neither do their employers. It's not necessarily possible to pull an unlimited budget out of the air or support a rapid turnaround. The kind of thinking that might make sense for a cashcow such as IBM might not be appropriate for small to medium companies.
I always strive to write high quality software upfront but also take the time needed to bring the software up to a minimum standard almost to the point of no matter what. What I don't do however is excess. Fowler provides plenty of ammunition for those prone to excess. There's always a competing axiom which is the more you do the more you have to do. Whatever you do ought offer the best value. The strongest drivers of cost effectiveness tend to be basic yet abstract principles such as YAGNI, DRY, consistency and good organisation and most of all being dedicated to purpose, not the the gospel of software engineering.
Time is a secondary factor. Things have to be done to a certain level. If not then you lose the game, when you sacrifice the present for the future too much then you reach the point where you have no future. Two thirds of the projects I've inherited are cases where developers have done that then moved on at the point where it just becomes too much for them to handle, onto the next thing for a new start. Usually level two developers end up having to take over level two projects where level one programmers have not only done as much as they can but have driven themselves into a deadend. Individual skill factors in far more than other factors or checklist items.
For me, in these circumstances, ironically code quality is absolutely crucial for a success. Elite teams taking "only an hour" to push a release? Asides from that not being qualified that's not by any means spectacular. This to me suggests a large discrepancy between people where it comes to experiences, expectations and standards It shouldn't be considered "elite" when a system facilitates development to production in under an hour. That's standard. If something takes an hour then there are usually special circumstances involved or it's just terribly constructed. I think to have a set of experiences where that's something to marvel only means he should get out even more to see what's happening in other shops.
Personally, I don't do it by the book and I won't buy the book.
Biting the hand that feeds IT
