The article is not saying "big feature" pipelines (where there is coordination across several teams) are inherently bad.
The article is disparaging that process if it is the only process. (And I've worked at companies where this was nearly true).
There must be efforts to experiment and refine (and possibly remove) existing features.
There must be efforts to refactor and improve existing code, to make it easier to maintain, less painful to be on-call, and make it possible to add subsequent features without breaking existing functionality.
You have to be able to do both large and incremental work to improve, in other words.
> There must be efforts to refactor and improve existing code
Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly.
This has yet to fail me. Granted, I don't work in embedded systems and my code is deployed on owned & operated servers that's easy to update.
Good for you for leaving things better than you found them.
But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey.
Ideally you'd get credit for the good work you do that makes the whole team more efficient.
being (sustainably) fast and producing quality code often go hand in hand. If management doesn’t know Cowboy Chris generates most of the debugging time, that’s a management problem.
A good management team is aware of which people are fast in short sprints but end up tangling things up on longer efforts, which people take time to build steam but never hit that slow-down, and which people fit other patterns (for example, the extremely rare fixers who can take Cowboy Chris’s shit and funnel it into something useful, or the even rarer speed demons who can sprint like that forever because they are like Chris but they work cleanly too)
Good engineers, given the chance, will find and stick with those managers too.
> But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey.
Maybe.
OTOH, not only can focussed refactoring make delivering the features it is associated with faster, but refactoring—delivery-focused or not—is a really good way tonbuild knowledge of and proficiency with a code base, so if you aren't doing huge quantities of non-germane refactoring, it can actually be a personal delivery-speed enhancer, as well as the benefits for the team.
My experience is that implicity is a huge problem as it's too often taken for granted and precisely not valued. Only when you stop doing people realize that since Jeff is on long leave server aren't updated and we've been hacked or that Lucy quited and everything seem to crawl to a halt because she implicitly was doing housekeeping on the database.
It might not have failed you yet but be sure the day it does there a good chance it will be spectacular.
The first sentence contradicts the other two and it contradicts the previous position where refactoring was done implicitly without anyone above in the org being aware of it.
A challenge I keep hitting with this is non-technical team asking 'why it takes this long' anytime the provided date is >X (for some X is a day, for others it's a week). They want to understand the internals of the ask so they can then nitpick that "well that's not needed". Fundamentally it's a lack of trust IMO, but any tips on addressing this would be welcome :-)
Which is usually a failure of communication. The whole "just trust us" bit doesn't work, and it takes real work to build a rapport with your stakeholders to earn "blind" trust, which is what most people are really asking for when they say "just trust us". This almost never happens, unless people have been working with each other for many years.
> then nitpick that "well that's not needed"
First, ask questions. Find out why they're willing to put energy into this - most people are not wasteful when they push back on things (most). Maybe their boss is riding their ass, and it's CYA. Maybe they're just stating a preference, so I'll ask questions to make this explicit ("So you just prefer it this way? No data? No customer feedback? Your boss didn't ask?").
Second, socialize things early and often. Tell people weeks, months, quarters in advance about some technical debt you're eventually going to get around to paying off. This gives people time to vent, challenge things, or say they're stupid. Use this time to refine your story, and get better at telling it in a way that gets the least resistance (don't need support, just fewer detractors).
Sometimes that "socializing" is complaining about a shared frustration. "Ugh, System X gobbled up Sharon's purchase order again and she has to spend another two hours after working salvaging things. Really wish they'd let us spend time fixing this, but you know how it goes."
By the time I've scheduled a meeting with stakeholders to discuss something (especially something I know will be difficult for them to see value in), I make sure I've individually discussed it with everyone in the room. When they see less disagreement between each other, there's less negative energy to build off. There may not be any positive energy, but that's much easier to deal with.
This only works for management, who are not actually doing any of the tangible work, but doing diversion work instead. For the kindergarden style teams, there are multiple non-productive diversion people already telling different stories to various other functions of the company. Then you have the next legs beyond that telling wilder stories. The dysfunction only grow worse as the system tries to scale the dysfunction.
Today most of business side has simply become too incompetent to be able to complete a dialogue with devs. Same goes for dev side, but is nothing new.
Sadly, it is experiential, both personal and observed in environment. Business people of today are great at monologues. Of course, management experience is different, and would hide the fact of hitting the wall as success.
This is interesting and will take some introspection, but perhaps I can improve these situations by fostering better communication. Thanks for taking the time to respond.
I really push this with my team. I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate. If you really can't get it done, you'll find out without eating everyone's time to debate whether you can. And if you get it done, great, things have improved.
Now, you will have other priorities. Make sure you aren't dropping them. But most things are communication based. In time, you will find ways to improve without disrupting. Backwards and forwards compatibility will be tools, not burdens. Stability of the core will similarly work for you, such that you may start choosing to leave parts alone as you focus on peripheral changes that will have clearer impact to users.
The stability part is hard to overstate. There is a reason the Arduino uno is relatively unchanged. There is massive value in having a stationary target for what you are building. Custom everything down the line is an easy recipe for failure. Even if there are improvements that can be made down that line.
> I will flat out reject stories that are "refactor". Instead, just do it, and spare us the prioritization debate.
Or alternatively, don't, because the message from management is that maintenance takes a back seat to shipping new features.
For example, my team has been using a home-brewed NodeJS-to-Kafka library. Now, everyone on the team understands that this library is suboptimal in a number of ways (most notably because the developer who wrote it is no longer with the company) and that it should be replaced by some alternative from Github. But this is a change that will require quite a few downstream changes (mostly because the way the existing library was used was not well-factored).
There's no way of doing this change without it being a separate story. It's just too big a change. It's also not really something that is easy to do efficiently in an incremental fashion -- having two Kafka libraries simultaneously in the codebase is an even worse situation to be in than having a single, suboptimal library. And management is not willing to authorize a separate story for a "refactoring" such as this one, even though it would result in significant operational savings (less memory usage, fewer server restarts, etc). So we bumble along, waiting until the pain becomes so severe that we're ordered to embark on a hasty rework in order to hurriedly patch in the new library when the system finally melts down.
I do work on embedded systems and it works there too. Much better in any kind of project though is if you can get a management team that actually sees the value in it.
I still consider it pretty much mandatory to build core system improvement into feature estimates but by being more explicit and interactive about it you can get good feedback to refine your own estimates of what parts are even worth improving. It may be that the product line that uses the subsystem you want to improve is about to go a new direction, for example, and the better thing to do is to start preparing for that subsystem to go away.
yes, refactoring is never something that I would plan as a standalone thing - it's just a part of building features or fixing bugs.
If you're going to be working on a part of the codebase that you know is difficult to work with, you need to pad your estimate whether you're planning to refactor it or not - either you use the time to do the refactor, or you use the time to sort out the bugs you introduced by working on scary code without refactoring.
> Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly.
This is the thing that I cannot agree with what so ever. Companies do not employ developers to write beautiful code. Companies employ developers to write code to support business. Every single code base that shipped contains warts that became obvious as soon as the final commit was one, which means that refactoring is a cost and costs need to be accounted for and prioritized according to business objectives ( which at the end is making money -- the money that pays developers salaries ).
Is it your claim that among FAANGs it is a normal practice to say "This will take X weeks" when in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X?
That these companies don't treat engineers as a cost structure the way you were talking about. This creates a drastically different culture since tech has a seat at the table, and the CFO can't just willy-nilly makes demands that impact the entire engineering organization without consent. It makes a big difference.
> That these companies don't treat engineers as a cost structure the way you were talking about.
That's absurd. The reason those companies are making money is because they are costing every single thing. That's the reason why tech gets a seat at the table -- it is a cost and its top of the line managers understand that this is a liability and drive that understanding through the entire tech organization.
> The reason those companies are making money is because they are costing every single thing
Terribly untrue. This is fundamentally what makes them "technology" companies, because of how engineering expenses are treated on the P&L and the say it has at the C-level.
There's a fundamental different between how things roll-up n your 3 sheets, vs. how your company internalizes those numbers and acts upon them.
You've made a lot of broad generalizations without backing anything up with specific examples. It's difficult to have a conversation with theoreticals and ideas.
> in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X
This is misleading, you should not be refactoring some other random code. You should be refactoring the code you are adding to/changing as part of the work. And it should be in proportion to the size of the change.
Who established the process control? The same developer that does the refactoring? Because if it is done by someone above him on the org chart then the developer has to either lie about what he is doing or he has to break it down into the refactoring + feature.
The practices you discuss are incidental, the real criticism the article makes is that there must be focus on measuring and delivering customer value; that h focus must be on impact rather than a train of features.
The article is disparaging that process if it is the only process. (And I've worked at companies where this was nearly true).
There must be efforts to experiment and refine (and possibly remove) existing features.
There must be efforts to refactor and improve existing code, to make it easier to maintain, less painful to be on-call, and make it possible to add subsequent features without breaking existing functionality.
You have to be able to do both large and incremental work to improve, in other words.