10 ms·

I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the ini

I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement. It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input. There is a reason that the points in this article exist at all - because the alternative is actually worse!

codingdave 7y ago
It is a question of balance. Don't do a process just for the sake of the process. Don't do a feature just for the sake of doing a feature. If you cannot tie those things to actual business goals, that is when you have a problem.
mceachen 7y ago
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.
- tomnipotent 7y ago
  > 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.
  - taeric 7y ago
    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.
    - quanticle 7y ago
      > 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.
- dragonwriter 7y ago
  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.
zomglings 7y ago
This has been my experience at every startup I've worked in before we found product market fit. Like you, I don't see the state this article describes as a bad thing. Sometimes, that's what it takes to survive.
- ClumsyPilot 7y ago
  And that makes sense, but I'd does wear you out.
sidlls 7y ago
This article isn't disparaging having a process for developing features or for maintaining a pipeline of features. It's disparaging conditions that prioritize the release of features for the sake of releasing features as opposed to for supporting the business' needs (as determined by data--including analysis of the performance of features, market conditions, and other factors). This article describes the last company I worked for very well: that company was and is struggling precisely because the senior leadership promoted a culture of feature releases without consideration for their impact and consistently changing the focus of feature development not based on data, but whim, so that the product was steadily losing focus and coherence.
- dragonwriter 7y ago
  > It's disparaging conditions that prioritize the release of features for the sake of releasing features Perhaps more to the point, it's disparaging having delivering features as the priority instead of delivering customer value.
- 0x445442 7y ago
  > as determined by data--including analysis of the performance of features, market conditions, and other factors What would be refreshing are internal ROI dash boards for each project and group instead of just technical dash boards. On almost every project I've worked on this data is not available and there's never any real evidence presented to the practitioners for things such as tech stack or process decisions. Typically, it's just a bunch of assertions, hand waiving and requests of trust.
  - BlueTemplar 7y ago
    Ultimately, we might be running into the issue that the impact is spread over time and cannot be condensed into a single ROI number ?
    - TheOtherHobbes 7y ago
      Impact is spread over time and multiple vectors. So now you have three problems in addition to getting working code the door - prioritising proposed features based on estimates of value, finding accurate metrics for assessing value after release, and mapping value changes over time. The nice thing about feature-driven-development is that it avoids the hard work of having to understand what you're actually doing. You can make the hamster wheel spin really fast and persuade yourself you're really going places. Until the wheel falls off.
hedora 7y ago
The article is describing a broken process that is often installed as organizations scale. If this matches what you’re currently installing, I suggest reconsidering your plans. Medium organizations do need more process than small ones, but not all processes are good. In particular, if you have a growing product, and the plan is to ship a ton of features without internal (to engineering) coordination, and without improving, or even maintaining the core product, then you’re probably doing more damage than good, and neither the developers nor the customers will thank you for it in the long run.
- ehnto 7y ago
  It would be important context to know if this is an agency or a product owner company. There is a whole spectrum of client-agency relationships, and some of them are more like a feature factory than others, and there's nothing wrong with that. Some companies want to hire a development team to work as if they were in house developers. Some clients just want to ask for Feature X and have Feature X delivered. They keep most of the discussions about business value, metrics and forward planning internally. It doesn't have to mean that you have a business with bad processes, it could just mean you have the latter client relationship and a fairly mature process of delivery that doesn't require constant turmoil, refactoring and retrospectives.
  - BlueTemplar 7y ago
    The general rule though is that the clients are asking for X, actually need Y, and get delivered Z - isn't it?
    - ehnto 7y ago
      That's often the case. If your agency is part of that discussion then you can provide enormous value to the client from your experience, and hopefully PMs are pulling the developer input up into discussions with clients as well. But then that is your relationship changing, and you can start to address many of the concerns in the article anyway. I guess my point is just that there are certain relationships where it's just not your decision whether or not feature X is a good fit. I wouldn't want people reading this article thinking their company is broken, when it's just a different type of engagement. Sometimes the CEO wants a popup on the homepage, and every single person in the chain between the CEO of the client company and the Developer at the agency agrees that it's a bad idea, but you still have to implement it.
strken 7y ago
I don't understand what you mean. A quarter of the items - "no measurement", "no connection to metrics", "no PM retrospectives" - are directly calling out immature development processes which don't quantify success and failure. Many more - "success theatre", "infrequent acknowledged failures", "no tweaking", "chasing upfront revenue" - are the direct result of not knowing whether a project succeeded or failed. Are your initiatives somehow removing the third step of define problem -> build solution -> learn from solution -> define problem?
herval 7y ago
As someone working in my 2nd 1000+ developers “feature factory” company, this article describes exactly how things work here in general - and makes for a pretty disfuncional environment. At least in my experience, I think this article is pretty spot-on. If you see yourself just starting to drive to these sorts of initiatives - eg establishing “weekly cadence syncs” that require “wins”, or “virtual squads” as the main team structure, you still have time to ponder and avoid walking that path. Walking back from these cultural shifts is VERY hard.
- caseymarquis 7y ago
  What sort of thing does one make with 1000+ developers?
  - Aeolun 7y ago
    The same thing one makes with 5. Just really inefficiently.
    - collyw 7y ago
      We have a feature factory with 5 developers. we could do with more people OR we could do to simplify our product. Instead we keep adding more and more to the tech stack which is already difficult to keep on top of with such a small team....
Isamu 7y ago
No worries, most of the points boil down to: are you bothering to find out if the feature you shipped actually helped users? Is it actually helping to sell more product or keep existing customers happy? If you have that feedback, you are good, mostly. Then you will learn to ship what is important to the business.
- BlueTemplar 7y ago
  Yeah, also, about : > Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers at the conclusion of each sprint Lol, I've worked on "Waterfall" projects more agile than this...
vsareto 7y ago
You'd better be paying those devs the cost of doing everything
jiofih 7y ago
That’s funny. I work at a billion-dollar corp and agree with almost everything said in this article. This is not about “devs doing everything”, but about not replacing your value stream with busywork and misguided delivery metrics. It’s very much on point. I cannot imagine someone willingly adopting “no metrics”, “shiny objects”, “no retrospectives”, waterfall isolated processes, etc. so you must be just exaggerating? what exactly are your new efforts like?
underwater 7y ago
Done poorly, all that process is going to hurt you. You'll end up with teams of people who know their role, celebrate the process, but don't know or care how to connect their work back to the bigger picture. Agile and Sprints can lead to this. You will see a lot of ceremony, and the team might increase their throughout. But you find your team disenfranchised and producing substandard code that doesn't really do what it needs to do.
btilly 7y ago
I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement. It is impossible to verify with as little context as you have given whether this is a good or a bad thing. But it clearly has a lot of bad in it. In the case of an "enterprise software project", the sales process is driven by feature lists. The result is described very well by https://www.mail-archive.com/kragen-tol@canonical.org/msg00109.html https://www.mail-archive.com/kragen-tol@canonical.org/msg001.... As frustrating as it may be for developers, a "feature factory" is in fact a rational outcome for the business. If, however, you are trying to deliver real value to real existing customers who have real use cases, it is very, very important that you find ways to measure outcomes. The measurements might be internal to your clients, they can be soft, but they have to be measured. If you do not have such measurements, and there isn't transparency around them, then it is guaranteed that people aren't getting useful feedback upon which they can do better. It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input. I'm sorry, but this paragraph sounds like a pile of red flags wrapped up in a self-serving excuse. As an experienced software developer with decades of experience who has worked at companies like eBay and Google, being told this by management would make me question whether it is time to find a new job before this one goes downhill. Yes, you want PMs to have a good sense of what is actually needed and to be an interface. No, you don't want devs involved in every choice. But I have never seen a PM who is as good as a good dev at looking at a customer need and figuring out whether there is a minor tweak to what already exists that can satisfy that need without building a new feature. And a system built as a collection of features that the devs have no context on is guaranteed to go wrong. If you shut the dev side of your organization out of those conversations, I can guarantee bad results. No matter what excuses you give for your decisions. There is a reason that the points in this article exist at all - because the alternative is actually worse! This is dead wrong. An example of an alternative that is appropriate for a lot of web companies (for example Google, Amazon and Booking) is an A/B test culture. Release features as A/B tests with transparent metrics. Share the metrics with everyone who is part of the decision INCLUDING devs. Proceed with general rollout of the features that actually produce positive results and rollback of the ones that don't. When every feature has to be justified by actual customer impacts that have a concrete measurement attached, you get a much better product and more involved devs. The flip side is that when you start a project you have no idea whether you add millions per year to the bottom line or whether your feature will be a flop. The challenge is that PMs and devs have to be willing to accept that sometimes they were wrong and that's OK. But the alternative is significantly worse, which is to have PMs and devs who are often wrong, refuse to accept it, and therefore fail to improve!

I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement. It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input. There is a reason that the points in this article exist at all - because the alternative is actually worse!

codingdave 7y ago

It is a question of balance. Don't do a process just for the sake of the process. Don't do a feature just for the sake of doing a feature. If you cannot tie those things to actual business goals, that is when you have a problem.

mceachen 7y ago

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.

tomnipotent 7y ago
> 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.
- taeric 7y ago
  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.
  - quanticle 7y ago
    > 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.
dragonwriter 7y ago
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.

zomglings 7y ago

This has been my experience at every startup I've worked in before we found product market fit. Like you, I don't see the state this article describes as a bad thing. Sometimes, that's what it takes to survive.

ClumsyPilot 7y ago
And that makes sense, but I'd does wear you out.

sidlls 7y ago

This article isn't disparaging having a process for developing features or for maintaining a pipeline of features. It's disparaging conditions that prioritize the release of features for the sake of releasing features as opposed to for supporting the business' needs (as determined by data--including analysis of the performance of features, market conditions, and other factors). This article describes the last company I worked for very well: that company was and is struggling precisely because the senior leadership promoted a culture of feature releases without consideration for their impact and consistently changing the focus of feature development not based on data, but whim, so that the product was steadily losing focus and coherence.

dragonwriter 7y ago
> It's disparaging conditions that prioritize the release of features for the sake of releasing features Perhaps more to the point, it's disparaging having delivering features as the priority instead of delivering customer value.
0x445442 7y ago
> as determined by data--including analysis of the performance of features, market conditions, and other factors What would be refreshing are internal ROI dash boards for each project and group instead of just technical dash boards. On almost every project I've worked on this data is not available and there's never any real evidence presented to the practitioners for things such as tech stack or process decisions. Typically, it's just a bunch of assertions, hand waiving and requests of trust.
- BlueTemplar 7y ago
  Ultimately, we might be running into the issue that the impact is spread over time and cannot be condensed into a single ROI number ?
  - TheOtherHobbes 7y ago
    Impact is spread over time and multiple vectors. So now you have three problems in addition to getting working code the door - prioritising proposed features based on estimates of value, finding accurate metrics for assessing value after release, and mapping value changes over time. The nice thing about feature-driven-development is that it avoids the hard work of having to understand what you're actually doing. You can make the hamster wheel spin really fast and persuade yourself you're really going places. Until the wheel falls off.

hedora 7y ago

The article is describing a broken process that is often installed as organizations scale. If this matches what you’re currently installing, I suggest reconsidering your plans. Medium organizations do need more process than small ones, but not all processes are good. In particular, if you have a growing product, and the plan is to ship a ton of features without internal (to engineering) coordination, and without improving, or even maintaining the core product, then you’re probably doing more damage than good, and neither the developers nor the customers will thank you for it in the long run.

ehnto 7y ago
It would be important context to know if this is an agency or a product owner company. There is a whole spectrum of client-agency relationships, and some of them are more like a feature factory than others, and there's nothing wrong with that. Some companies want to hire a development team to work as if they were in house developers. Some clients just want to ask for Feature X and have Feature X delivered. They keep most of the discussions about business value, metrics and forward planning internally. It doesn't have to mean that you have a business with bad processes, it could just mean you have the latter client relationship and a fairly mature process of delivery that doesn't require constant turmoil, refactoring and retrospectives.
- BlueTemplar 7y ago
  The general rule though is that the clients are asking for X, actually need Y, and get delivered Z - isn't it?
  - ehnto 7y ago
    That's often the case. If your agency is part of that discussion then you can provide enormous value to the client from your experience, and hopefully PMs are pulling the developer input up into discussions with clients as well. But then that is your relationship changing, and you can start to address many of the concerns in the article anyway. I guess my point is just that there are certain relationships where it's just not your decision whether or not feature X is a good fit. I wouldn't want people reading this article thinking their company is broken, when it's just a different type of engagement. Sometimes the CEO wants a popup on the homepage, and every single person in the chain between the CEO of the client company and the Developer at the agency agrees that it's a bad idea, but you still have to implement it.

strken 7y ago

I don't understand what you mean. A quarter of the items - "no measurement", "no connection to metrics", "no PM retrospectives" - are directly calling out immature development processes which don't quantify success and failure. Many more - "success theatre", "infrequent acknowledged failures", "no tweaking", "chasing upfront revenue" - are the direct result of not knowing whether a project succeeded or failed. Are your initiatives somehow removing the third step of define problem -> build solution -> learn from solution -> define problem?

herval 7y ago

As someone working in my 2nd 1000+ developers “feature factory” company, this article describes exactly how things work here in general - and makes for a pretty disfuncional environment. At least in my experience, I think this article is pretty spot-on. If you see yourself just starting to drive to these sorts of initiatives - eg establishing “weekly cadence syncs” that require “wins”, or “virtual squads” as the main team structure, you still have time to ponder and avoid walking that path. Walking back from these cultural shifts is VERY hard.

caseymarquis 7y ago
What sort of thing does one make with 1000+ developers?
- Aeolun 7y ago
  The same thing one makes with 5. Just really inefficiently.
  - collyw 7y ago
    We have a feature factory with 5 developers. we could do with more people OR we could do to simplify our product. Instead we keep adding more and more to the tech stack which is already difficult to keep on top of with such a small team....

Isamu 7y ago

No worries, most of the points boil down to: are you bothering to find out if the feature you shipped actually helped users? Is it actually helping to sell more product or keep existing customers happy? If you have that feedback, you are good, mostly. Then you will learn to ship what is important to the business.

BlueTemplar 7y ago
Yeah, also, about : > Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers at the conclusion of each sprint Lol, I've worked on "Waterfall" projects more agile than this...

vsareto 7y ago

You'd better be paying those devs the cost of doing everything

jiofih 7y ago

That’s funny. I work at a billion-dollar corp and agree with almost everything said in this article. This is not about “devs doing everything”, but about not replacing your value stream with busywork and misguided delivery metrics. It’s very much on point. I cannot imagine someone willingly adopting “no metrics”, “shiny objects”, “no retrospectives”, waterfall isolated processes, etc. so you must be just exaggerating? what exactly are your new efforts like?

underwater 7y ago

Done poorly, all that process is going to hurt you. You'll end up with teams of people who know their role, celebrate the process, but don't know or care how to connect their work back to the bigger picture. Agile and Sprints can lead to this. You will see a lot of ceremony, and the team might increase their throughout. But you find your team disenfranchised and producing substandard code that doesn't really do what it needs to do.

btilly 7y ago

I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement. It is impossible to verify with as little context as you have given whether this is a good or a bad thing. But it clearly has a lot of bad in it. In the case of an "enterprise software project", the sales process is driven by feature lists. The result is described very well by https://www.mail-archive.com/kragen-tol@canonical.org/msg00109.html https://www.mail-archive.com/kragen-tol@canonical.org/msg001.... As frustrating as it may be for developers, a "feature factory" is in fact a rational outcome for the business. If, however, you are trying to deliver real value to real existing customers who have real use cases, it is very, very important that you find ways to measure outcomes. The measurements might be internal to your clients, they can be soft, but they have to be measured. If you do not have such measurements, and there isn't transparency around them, then it is guaranteed that people aren't getting useful feedback upon which they can do better. It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input. I'm sorry, but this paragraph sounds like a pile of red flags wrapped up in a self-serving excuse. As an experienced software developer with decades of experience who has worked at companies like eBay and Google, being told this by management would make me question whether it is time to find a new job before this one goes downhill. Yes, you want PMs to have a good sense of what is actually needed and to be an interface. No, you don't want devs involved in every choice. But I have never seen a PM who is as good as a good dev at looking at a customer need and figuring out whether there is a minor tweak to what already exists that can satisfy that need without building a new feature. And a system built as a collection of features that the devs have no context on is guaranteed to go wrong. If you shut the dev side of your organization out of those conversations, I can guarantee bad results. No matter what excuses you give for your decisions. There is a reason that the points in this article exist at all - because the alternative is actually worse! This is dead wrong. An example of an alternative that is appropriate for a lot of web companies (for example Google, Amazon and Booking) is an A/B test culture. Release features as A/B tests with transparent metrics. Share the metrics with everyone who is part of the decision INCLUDING devs. Proceed with general rollout of the features that actually produce positive results and rollback of the ones that don't. When every feature has to be justified by actual customer impacts that have a concrete measurement attached, you get a much better product and more involved devs. The flip side is that when you start a project you have no idea whether you add millions per year to the bottom line or whether your feature will be a flop. The challenge is that PMs and devs have to be willing to accept that sometimes they were wrong and that's OK. But the alternative is significantly worse, which is to have PMs and devs who are often wrong, refuse to accept it, and therefore fail to improve!