41–49 of 49 posts
Shameless plug: https://leadership.garden/tips-on-prioritizing-tech-debt/
While the article delivers nice explanations for what kind of technical dept exist, it stays very generic and hand-wavy for the solutions. Bringing "microservices" into the room is definitely not helpful. Ownership and setting a quality bar..., sure but how does that look like? As I developer I maybe have an idea but I also need to sell that to management. As manager I have an idea too but I need to convince my devel…
This is Fowler (and Uncle Bob's) stock in trade tbh.
Generic good advice that sounds plausible in a sane world.
Without ever acknowledging that we actually don't live in that world.
Earlier quoted context omitted.
I pretty much lost respect for him when he started advocating short methods. From [1]: > In my Ruby code, half of my methods are just one or two lines long. 93% are under 10. Are there professional engineers out there who reads this tweet and thinks striving for one or two lines methods is a good idea? I really don't understand how does this person have so much fame or so much authority on architectures? What exactly…
Cargo cult programming at it's maximum expression. M. Fowler, Uncle Bob, Kent Beck, GoF authors... Any book or post by these people is always brought up as a must read. A must read to understand why you should *not follow cargo cults* and see with your own eyes how toxic and damaging these guys are to software engineering culture. In one hand, I'd say these guys are absolutely revered among computer science students…
I'm somewhat glad I made it out the other side; as a babe in arms programmer I was fully taken in by these ideas. It's a great game of fun creating these overly complex, but ultimately arbitrary, sets of rules. They serve no real purpose other than creating and solving mental puzzles. There's a reason Software Architects don't (shouldn't) exist any more.
Earlier quoted context omitted.
And if complexity can be designed out from day zero with a clear and concise foundational development model to follow then the technical debt can be greatly reduced as well. This of course conflicts with the global rush into tech to build something as fast as possible to get to revenue and not investing the time proactivity to build for the long game. Planning and control are my two points that get extreme focus in d…
Designed out on day zero is the siren song of waterfall. Getting it right the first time is a very hard game to win. It’s best to save some of your energy for the times that really count. It’s always interesting to me when coworkers exclaim that doing the right thing is too hard. Reminds me of myself at age nine trying to get out of chores. More seriously though, “if it hurts stop doing it” is how dumb animals think.…
"Getting it right the first time is a very hard game to win."
I cannot disagree if it is one's first time yet this is my sixth and I have no losses to date. I have nothing but time and so in that time I will see how this game plays out.
Earlier quoted context omitted.
Designed out on day zero is the siren song of waterfall. Getting it right the first time is a very hard game to win. It’s best to save some of your energy for the times that really count. It’s always interesting to me when coworkers exclaim that doing the right thing is too hard. Reminds me of myself at age nine trying to get out of chores. More seriously though, “if it hurts stop doing it” is how dumb animals think.…
After decades of software development experience inclusive of 24/7 on call support while also being the person of which ALL bucks stopped I personally have lived that "hurt" too many times to count. If time can be invested prior by designing out those problems, looking back now, then this is something only experience could bring since one does not know what they do not know. "Getting it right the first time is a very…
Everything else is just annoyance, and lumping those in with the others ends up pulling attention away from the ones that really matter, meaning those solutions get compromised on quality.
Leaving space for a solution is not the same thing as creating an abstraction for a solution, and most people don't get that. Architectural astronauts elevate this blind spot to performance art, and none more profoundly than J2EE architects, as lampooned by Enterprise FizzBuzz: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
I wonder sometimes if some of my former coworkers' cognitive dissonance ends at the office door, or if at home they hang empty picture frames on their walls as placeholders for when they eventually find some art they like, put armchair-shaped boxes labeled "Chair" in their living rooms, dolls in empty cribs and stuffed animals in empty pet beds.
Earlier quoted context omitted.
Have you read his books or just his tweets? 1-line methods is taking things to an extreme (though you can write a lot of logic into a single line in Ruby, so maybe it's not as crazy as it would be in C...) but I found the discussion in his refactoring book about reorganizing methods and naming things very illuminating. It's an idea so simple it sounds stupid sometimes to try to explain to people, and yet, I never sto…
https://wiki.c2.com/?ScreechinglyObviousCode
The one that snuck up on me was sort of the corollary to Screechingly Obvious Code, and a cousin to Pandora's Box - which is, strictly speaking, and antipattern (except that in the end of the original story, Hope was left in the box).
If you have a function that is Obvious except for one small part, factor it out into its own function. The care comes in picking the incision points. The inputs and outputs to the new method need to be obvious (ie, don't factor out a function with side effects, that makes for spooky action at a distance), which may require some temporary data structures in order to iron out.
Going further, if you are considering a behavioral change that may not be obvious (performance optimization, error handling for very obscure cases) that has no prayer of being screechingly obvious, determine what lines will need to be changed, extract method on that code first, commit it, and only then make the change to the extracted code. Mikado method often comes into play here. Get used to revisionist commit history techniques.
What I've found through long observation is that people are more comfortable reverting such changes if they break when you are not there, which in turns make them more open to approving the change in the first place. "Will this bite me on the ass later?" is a pretty important consideration for most people. The commit history is very clean, and someone can revisit your decision years from now, when your user base and hardware are orders of magnitude bigger, when the runtime and hardware have very different timing ratios between different activities, and so on. And critically (for the optimization obsessed), compilers are very good at inlining leaf functions, which means the 'cost' of the context switch can be negligible in practice.
Also I don't know about anyone else but I've found that my attachment to such code is also fairly low. You are much more likely to get encouragement to 'go for it' when broaching the subject of undoing one of these changes, instead of a lecture about watching for regressions (I tend to "over-invest" in robustness, so deleting my code statistically represents a reversion to the mean wrt to code quality).
And perhaps more importantly to this conversation, they tend to tune out these leaf node methods when tracing code looking for bugs or trying to add new features, bugfixes. These structures don't nerdsnipe us, causing us to dump state on short term memory and have to start over. If I had a dollar for every time I said, "Aha! I found the place where we return null! Wait, why was I looking for that?" I could retire. This is, in my mind, the critical quality of Screechingly Obvious Code - in uses up a single slot of short term memory, facilitating code traversal.
Earlier quoted context omitted.
> It's a pretty good way to increase technical debt. The microservices themselves might become small enough that it is easy to refactor some at a time, but then you have the actual deployment and communication infrastructure to contend with. And if you get that architecture wrong, oh boy you'll be begging to go back to a monolith in a day. I remember at a previous job, the monolith was drowning in technical debt. Som…
> I remember at a previous job, the monolith was drowning in technical debt. Someone decided the solution was Go microservices. Fast-forward 18 months and 95% of the functionality is still in the monolith, but there are now 25 microservices, and no environment (except production) where you can test everything together. I have the opposite anecdote. Currently working on a monolith that's been around for 5-7 years, hug…
But it wasn't broken up because it was too hard to update dependencies, it was broken up because it was a complicated mess. They just traded it off for another complicated mess.
Earlier quoted context omitted.
Could not agree more. The solution to tech debt is the one nobody wants to hear: Slow down! Steve Jobs' presentation of Snow Leopard should be mandatory viewing for every manager. "No new features" to a standing ovation. Customers actually like stable, responsive, and efficient tools, who would have thought? EDIT: > Bringing "microservices" into the room is definitely not helpful It's a pretty good way to increase te…
> Customers actually like stable, responsive, and efficient tools, who would have thought? _Existing_ customers like these things (and they aren't wrong for liking these things). New business comes from the potential customers who weren't enticed by the existing feature set, robust or otherwise. You bring them in by adding new features. The retain/new business priority is often heavily weighted in favor of the latter…
Earlier quoted context omitted.
The problem is you eventually need the things k8s offers and you end up implementing part of k8s, badly. I've seen bigish places that state "we aren't Google" as an argument to not use k8s, containers, etc but don't consider that their tech stacks are a Hodge Podge of bespoke glue, a mass of technical debt and a bus factor of generally 1 or 2.
The question they should be asking isn't "is this tech stack perfect or a mess" it's "is this actively preventing, or about to prevent, us from meeting our uptime and cost and development goals"? The idea that a shop that built a messy system will suddenly build a non-messy system just if they pick up a new set of tools - that they don't have practice with anyway! - is exactly the silver-bullet fallacy. The system tu…