7 ms·

Enabling choice for Agile delivery Scrum teams

37 points by dwiamo 10y ago

Xorlev 10y ago
Too much chaos and choice and you slow down because everyone has done the same things in slightly different ways. There's a fine balance between allowing choice and setting standards. There's productivity gains as well from having some standards -- you can built tools which leverage standards, so long as they aren't too restrictive. e.x. In the world of microservices, you end up needing a lot of telemetry to keep things running smoothly and figure out what goes wrong when your call is four levels deep. Doing so is hard without having a standard to which your services must adhere to. It's easiest if you have a base application which takes care of that for you. That, however, becomes hard if you have the combinatorial explosion of [languages] x [frameworks]. That doesn't mean you shouldn't entertain new choices, (hey, team X wants to use Go.) but there should be some discipline. It boggles my mind when individual engineers prefer to speed up their development for the short-term vs. the overall organization.
karka91 10y ago
I work for a shop with more than 200 devs. Over the years we had multiple efforts to standardize the libraries, platforms we use only to very limited success. While things like CI software and IDE got pretty much standard without any intervention to this day there is no consensus for library x to do y. The overall sentiment resonates with me and what I've seen at my workplace
heisenbit 10y ago
Creating software is about making the right decisions at the right point in time. Any decision by nature restricts choice. It is precisely the job of CTOs and architects to make decisions about partners, platforms, tooling and frameworks and to refrain from making these decisions at other times. Should you empower teams to make their stack choices? I've seen chaos breaking out for a year in a major development organization with 500 devs when most teams suddenly were allowed to make some choices that better should have been made centrally. Yes, they were faster but they were faster going nowhere. And then there are all these aspects that go beyond the development phase - long term maintenance, behavior of software in the field / training field engineers and moving people across teams. Good technical leaders know where choice is called for and where not. Managing these trade-offs requires a perspective that goes beyond the agile team.
- dwiamo 10y ago
  I agree, thats where the absolutes come in. Some choices need to be made centrally and the teams must stick to them, this is where choice can really work, when the lines are drawn and the structure clear.
- ChemicalWarfare 10y ago
  I would add that one way to gently enforce the stack when the system is getting built from scratch is having a solid end-to-end "POC"/"skeleton"/whatever you want to call it built by a senior architect before the rest of the team is brought in. Sure this requires an "architect who codes" type person to be involved (which can get expensive), as opposed to some ivory tower powerpoint architect but is typically worth it.
- donovanm 10y ago
  I think the problem is that individual teams will make decisions that make sense for their own individual team. These decisions may not make sense for the larger organization as a whole (ie. having every team working in a different programming language) as they don't have the birds eye view of the organization.
gm-conspiracy 10y ago
Creativity leads to anarchy.
dkhenry 10y ago
In my experience the team should be free to make whatever technical choice they want. The only reason you get dictation from on high about what choices should be made is because your technical leadership lacks the technical depth to advocate for a common stack that is actual useful. Every time I have seen an origination talk about standardizing on some language or framework and its hasn't grown out of the engineering community at that company its been because leadership didn't have a strong technical background and they were making choices based on marketing material, sales reps, or consultants. The best standardization I have seen grew out of a team who was empowered to make decisions, made good decisions, showed how their decisions were good for the entire origination and helped everyone migrate to one solution which turned out to be pretty good at solving everyone's problems. If you as a leader find yourself pushing a standard tool set to a team who is hesitant to adopt it the problem is most likely you.
- cookiecaper 10y ago
  You assume that everyone in the company is acting rationally, and that everyone has the same goals and values. This is usually not the case. The truth is that for most types of applications, there are several technology stacks that would be perfectly adequate. You get into the tradeoffs, and unless the benefit posed by a specific thing is immediately obvious, these are a matter of subjective judgment. Great technical minds will have differing subjective judgment; no one's judgment is exactly same as another's. People also usually do not understand their own motives. This is the origin of fads. Everyone suddenly agrees that THING_Y is the best, and then, the next year, everyone suddenly believes it's THING_Z now. If someone can present a dense, semi-passable argument in favor of it, the rest of the uptake comes down to marketing. This is true no matter how smart you think you are. If you have a technician who prides themselves on always knowing about new technologies, and that's their reputation, it's likely their primary motivating factor will be continuing to propagate that self-image. They might not even realize it. They will come and say "There is a new tech called TECH_X and it allows us to do these amazing new things!" As long as TECH_X has some value proposition and isn't a blatant or obvious bad fit (meaning obvious and blatant to everyone), their argument is plausible enough and they'll run with that. They think they're doing this because they learn all the new things and it gives them a competitive edge. In reality, it's because they view themselves as cutting edge, they want everyone else to view them as cutting edge, and need to feed themselves and everyone else some proof validating that desirable conception. The difference between "political schemers" and your average employee generally comes down to their naivety around the universality and importance of these functions. Which is another danger -- the less-naive employees in the ranks will be actively working their own angles here to attempt to manipulate the psychology of the people around them. This can and does invade technical choices. You can make the best arguments in the world for your stack, but if you have a political competitor, they will work to undermine you, often in non-obvious ways. If they feel now is the time to strike and they can embarrass you, they'll do so; if not, they'll agree and subtly work to sabotage your plan. There's another type of employee here; the type who wants to keep his day job on cruise control, and will oppose anything new because it would make his short-term daily existence more difficult (and perhaps long-term if the improvement could reduce inefficiencies so much that he becomes redundant), regardless of organizational benefit. There are many arguments to be made in favor of keeping the status quo, so he will look OK; if your new stack is a wild success, he will be able to say "Oh, I just needed some time to come around" and if your new stack is an abject failure (which happens much more often than people wish to admit, and even more often, it's made to appear an abject failure by political competitors regardless), he will be able to say "I told you so". People are naturally self-interested and will behave that way all that time. Management must look outside of the individual goals of the employee or team and consider what is in the long-term interest of the organization. tl;dr This is naive; a purely democratic approach doesn't work because people's goals and values don't necessarily align.
rb808 10y ago
Too many technologies is a problem so teams shouldn't be able to choose anything. My wider team is 50 people made up of ~8 smaller teams. We have some flexibility to choose technology with the result of our new product: * Core system JVM * Python wrapper for web service API * C# scraping calling the web service * JS/node webserver calling the C# layer As a result its slow, messy and difficult to maintain. Would be nice if managers prevented small teams from choosing any technical choice they felt like.
- yawz 10y ago
  > Would be nice if managers prevented small teams from choosing any technical choice they felt like. That requires knowledge, experience, and good technical & business judgement. Unfortunately not everyone has these qualities. Refusing something simply for keeping things as they are is not a sustainable strategy in technology. Decisions have to be made smart, and they have to contribute to the incremental improvements.
diminoten 10y ago
As a person who this article is saying should be empowered to have more choice, choice is a dog whistle for Not Invented Here. The people you employ to build your software will often make the straight up wrong choice when given the opportunity, and a lot of that time the "choice" will be to homebrew a solution that already exists elsewhere, because it's perceived as simpler than taking the time to understand an existing technology. The reasons that get hand waved away in this article are exactly the reasons you can't ignore consistency across teams. There is value in having just one library that multiple teams use to communicate via HTTP to various services, there is value in members of different teams being able to work across projects due to the similarities in infrastructure. If each team has their own client library for communicating with a service, that's work you've paid for twice, or more. I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because that is valuable. Letting the folks building the stuff decide which things to build first is much more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don't get too wrapped up in them). Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with. There, I don't think choice is good, at least not for everyone. Maybe this is written for my boss's boss, I dunno. But as for me, the dev writing the code, I don't really want me (or my colleagues) to have all that much choice.
- dkhenry 10y ago
  Its interesting trying to figure out from your comment what kind of people you intend on working with. On one hand you conclude that given the opportunity your employees will wake the wrong choice. So if you can't trust them to make good decisions what do you trust them with? If they can't make tooling choices can they make algorithmic choices, if they can't make algorithmic choices can they really decide what kind of language constructs to use. If I can't trust you to make a good choice on which technology to use why do I think I can trust you to make good choices in other aspects of your job. If you don't feel confident to make a technical choice then what you are telling me is you don't understand, and don't want to learn. Not really a desirable quality.
cookiecaper 10y ago
Everyone should know about Conway's Law [0], especially in the age of microservices. I currently work in an environment where there is virtually no central technical management. There are groups of 2-4 developers who roam around their department's problem space, making whatever choices they want. If someone doesn't like the interface on one microservice, they fork the code and make a new one. This leads to 5 microservices that accomplish the same thing, and 5x the maintenance burden whenever something changes. I've derisively called these "nanoservices", but I need a more offensive term. People intentionally choose techs that no one else in the company has used, trying to cement their position and hedge up potential competition or unwelcome cooperation. They also select technology for the best PR effect, being able to say "We're being like Google today". The result is a whole mess of different stuff running throughout production, each needing its own backup system, etc., which, to be honest, does not always get installed. It's a disaster. The author's contention is that giving more choice to teams is better because it makes them feel more ownership in their product. That's fine, but do recognize that this is a psychological solution to a management problem. The job of the manager is to actively control the psychology of employees and the structure of the organization such that employees are happy to do things that lead to cooperation, not to allow employees to always get their way. Without a central coordinating force and everyone's acknowledgement that some compromise and sacrifice is necessary, everything falls apart quickly. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- dkhenry 10y ago
  Conway's Law in your environment should probably be interpreted that you have a team that can't talk or work together at all. It has nothing to do with what technical choices they are making, even if you imposed a rigid technical structure you would still have divergent nanoservices because your team can't communicate.
  - cookiecaper 10y ago
    No, it's not that they're incapable of working together. It's that they have no incentive to do so. They can do whatever they want now and improve their own positions by so doing, so why shouldn't they? Normally, people don't do this a) because they don't want to be required to deal with the cruft or b) because they believe someone will observe their bad behavior and stop it. They don't really have to deal with the cruft, and it's clear now that no one in this organization will hold them accountable, so why should they waste time and energy trying to build a consistent platform? re: Conway's Law, the organization's communication mechanisms are loose and ad-hoc; there is no central coordination. Consequently, the software is coordinated on a loose, ad-hoc basis between small teams. The same featureset will be implemented 4 times by 4 different teams, not because they can't talk (there is an office where most people hang out together all day, and people do generally keep an awareness of what the other group is working on), but because they'd rather just do it the way they want to do it. It's not that no one ever ends up sharing anything. It's just that instead of having a discussion and making consistent decisions about the platform, they just do what they want, because they can.
MaulingMonkey 10y ago
I don't have a choice: I must use a broad array of tools and languages. The gamedev stuff I've helped tackle fundamanetlaly required mostly C++... and a little C, and some x86/ARM/PPC for debugging, HLSL 3-5/GLSL ES/PSSL/<custom shader DSLs> for porting graphics, at least two shell scripting languages for CI servers (Bash, and Powershell or (ew!) Batch), Python (for various modeling tools)... Java, Objective C, and C++/CX for platform specific APIs... MSBuild, Makefiles, Gradle, Ant... and that's just the languages! The tooling front is no better. A handful more language choices that theoretically could've been avoided (e.g. C# for tools and server stuff, ActionScript for UI) is really not that big a deal in this context. You can add pointless layers of cruft, but I've only seen it once - a Python script used to hack up the result of a C++ program. Even then they had a reason: some of the C++ didn't get checked in, so we couldn't even build the C++ program. (A happy ending: With a little reverse engineering of the resulting binary output, I was able to re-implement the missing C++ bits, implement the Python-script 'fixes' more cleanly in the original C++, and add my own necessary changes on top of that.)
quantumhobbit 10y ago
Wow the comments here certainly seem to be against allowing developers any input in the tools they use. I guess you all are part of the reason I have to use Java 7 and outdated versions of Angular in my day job no matter their applicability to the problem domain and have no input in those decisions. I agree that total anarchy is bad in the workplace, but don't you think that the people using the tools should have some input in choosing the tools?
- yawz 10y ago
  I, for one, want to see something beyond the shiny-toy syndrome when I talk to a team member about why we need to use the tool/technology/framework/library in question. I'm all for personal improvement, and every technology, regardless how different it is, that we learn/become familiar with makes us better professionals. But sandbox to production is a long way. Keeping things simple has its merits.
Zigurd 10y ago
Choices break naturally on time and platform boundaries. New projects should review stack choices, and enforcing cross-platform stacks is usually too brittle.
nradov 10y ago
He seems to be ignoring long-term maintenance costs. If you're building a $0.99 app then sure let the team pick whatever they want. But if you're building a huge SaaS web application with an expected 20 year lifecycle then that cuts the range of sensible choices way down.

37 points by dwiamo 10y ago

Too much chaos and choice and you slow down because everyone has done the same things in slightly different ways. There's a fine balance between allowing choice and setting standards. There's productivity gains as well from having some standards -- you can built tools which leverage standards, so long as they aren't too restrictive. e.x. In the world of microservices, you end up needing a lot of telemetry to keep things running smoothly and figure out what goes wrong when your call is four levels deep. Doing so is hard without having a standard to which your services must adhere to. It's easiest if you have a base application which takes care of that for you. That, however, becomes hard if you have the combinatorial explosion of [languages] x [frameworks]. That doesn't mean you shouldn't entertain new choices, (hey, team X wants to use Go.) but there should be some discipline. It boggles my mind when individual engineers prefer to speed up their development for the short-term vs. the overall organization.

karka91 10y ago

I work for a shop with more than 200 devs. Over the years we had multiple efforts to standardize the libraries, platforms we use only to very limited success. While things like CI software and IDE got pretty much standard without any intervention to this day there is no consensus for library x to do y. The overall sentiment resonates with me and what I've seen at my workplace

heisenbit 10y ago

Creating software is about making the right decisions at the right point in time. Any decision by nature restricts choice. It is precisely the job of CTOs and architects to make decisions about partners, platforms, tooling and frameworks and to refrain from making these decisions at other times. Should you empower teams to make their stack choices? I've seen chaos breaking out for a year in a major development organization with 500 devs when most teams suddenly were allowed to make some choices that better should have been made centrally. Yes, they were faster but they were faster going nowhere. And then there are all these aspects that go beyond the development phase - long term maintenance, behavior of software in the field / training field engineers and moving people across teams. Good technical leaders know where choice is called for and where not. Managing these trade-offs requires a perspective that goes beyond the agile team.

dwiamo 10y ago
I agree, thats where the absolutes come in. Some choices need to be made centrally and the teams must stick to them, this is where choice can really work, when the lines are drawn and the structure clear.
ChemicalWarfare 10y ago
I would add that one way to gently enforce the stack when the system is getting built from scratch is having a solid end-to-end "POC"/"skeleton"/whatever you want to call it built by a senior architect before the rest of the team is brought in. Sure this requires an "architect who codes" type person to be involved (which can get expensive), as opposed to some ivory tower powerpoint architect but is typically worth it.
donovanm 10y ago
I think the problem is that individual teams will make decisions that make sense for their own individual team. These decisions may not make sense for the larger organization as a whole (ie. having every team working in a different programming language) as they don't have the birds eye view of the organization.

gm-conspiracy 10y ago

Creativity leads to anarchy.

dkhenry 10y ago

In my experience the team should be free to make whatever technical choice they want. The only reason you get dictation from on high about what choices should be made is because your technical leadership lacks the technical depth to advocate for a common stack that is actual useful. Every time I have seen an origination talk about standardizing on some language or framework and its hasn't grown out of the engineering community at that company its been because leadership didn't have a strong technical background and they were making choices based on marketing material, sales reps, or consultants. The best standardization I have seen grew out of a team who was empowered to make decisions, made good decisions, showed how their decisions were good for the entire origination and helped everyone migrate to one solution which turned out to be pretty good at solving everyone's problems. If you as a leader find yourself pushing a standard tool set to a team who is hesitant to adopt it the problem is most likely you.

cookiecaper 10y ago
You assume that everyone in the company is acting rationally, and that everyone has the same goals and values. This is usually not the case. The truth is that for most types of applications, there are several technology stacks that would be perfectly adequate. You get into the tradeoffs, and unless the benefit posed by a specific thing is immediately obvious, these are a matter of subjective judgment. Great technical minds will have differing subjective judgment; no one's judgment is exactly same as another's. People also usually do not understand their own motives. This is the origin of fads. Everyone suddenly agrees that THING_Y is the best, and then, the next year, everyone suddenly believes it's THING_Z now. If someone can present a dense, semi-passable argument in favor of it, the rest of the uptake comes down to marketing. This is true no matter how smart you think you are. If you have a technician who prides themselves on always knowing about new technologies, and that's their reputation, it's likely their primary motivating factor will be continuing to propagate that self-image. They might not even realize it. They will come and say "There is a new tech called TECH_X and it allows us to do these amazing new things!" As long as TECH_X has some value proposition and isn't a blatant or obvious bad fit (meaning obvious and blatant to everyone), their argument is plausible enough and they'll run with that. They think they're doing this because they learn all the new things and it gives them a competitive edge. In reality, it's because they view themselves as cutting edge, they want everyone else to view them as cutting edge, and need to feed themselves and everyone else some proof validating that desirable conception. The difference between "political schemers" and your average employee generally comes down to their naivety around the universality and importance of these functions. Which is another danger -- the less-naive employees in the ranks will be actively working their own angles here to attempt to manipulate the psychology of the people around them. This can and does invade technical choices. You can make the best arguments in the world for your stack, but if you have a political competitor, they will work to undermine you, often in non-obvious ways. If they feel now is the time to strike and they can embarrass you, they'll do so; if not, they'll agree and subtly work to sabotage your plan. There's another type of employee here; the type who wants to keep his day job on cruise control, and will oppose anything new because it would make his short-term daily existence more difficult (and perhaps long-term if the improvement could reduce inefficiencies so much that he becomes redundant), regardless of organizational benefit. There are many arguments to be made in favor of keeping the status quo, so he will look OK; if your new stack is a wild success, he will be able to say "Oh, I just needed some time to come around" and if your new stack is an abject failure (which happens much more often than people wish to admit, and even more often, it's made to appear an abject failure by political competitors regardless), he will be able to say "I told you so". People are naturally self-interested and will behave that way all that time. Management must look outside of the individual goals of the employee or team and consider what is in the long-term interest of the organization. tl;dr This is naive; a purely democratic approach doesn't work because people's goals and values don't necessarily align.

rb808 10y ago

Too many technologies is a problem so teams shouldn't be able to choose anything. My wider team is 50 people made up of ~8 smaller teams. We have some flexibility to choose technology with the result of our new product: * Core system JVM * Python wrapper for web service API * C# scraping calling the web service * JS/node webserver calling the C# layer As a result its slow, messy and difficult to maintain. Would be nice if managers prevented small teams from choosing any technical choice they felt like.

yawz 10y ago
> Would be nice if managers prevented small teams from choosing any technical choice they felt like. That requires knowledge, experience, and good technical & business judgement. Unfortunately not everyone has these qualities. Refusing something simply for keeping things as they are is not a sustainable strategy in technology. Decisions have to be made smart, and they have to contribute to the incremental improvements.

diminoten 10y ago

As a person who this article is saying should be empowered to have more choice, choice is a dog whistle for Not Invented Here. The people you employ to build your software will often make the straight up wrong choice when given the opportunity, and a lot of that time the "choice" will be to homebrew a solution that already exists elsewhere, because it's perceived as simpler than taking the time to understand an existing technology. The reasons that get hand waved away in this article are exactly the reasons you can't ignore consistency across teams. There is value in having just one library that multiple teams use to communicate via HTTP to various services, there is value in members of different teams being able to work across projects due to the similarities in infrastructure. If each team has their own client library for communicating with a service, that's work you've paid for twice, or more. I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because that is valuable. Letting the folks building the stuff decide which things to build first is much more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don't get too wrapped up in them). Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with. There, I don't think choice is good, at least not for everyone. Maybe this is written for my boss's boss, I dunno. But as for me, the dev writing the code, I don't really want me (or my colleagues) to have all that much choice.

dkhenry 10y ago
Its interesting trying to figure out from your comment what kind of people you intend on working with. On one hand you conclude that given the opportunity your employees will wake the wrong choice. So if you can't trust them to make good decisions what do you trust them with? If they can't make tooling choices can they make algorithmic choices, if they can't make algorithmic choices can they really decide what kind of language constructs to use. If I can't trust you to make a good choice on which technology to use why do I think I can trust you to make good choices in other aspects of your job. If you don't feel confident to make a technical choice then what you are telling me is you don't understand, and don't want to learn. Not really a desirable quality.

cookiecaper 10y ago

Everyone should know about Conway's Law [0], especially in the age of microservices. I currently work in an environment where there is virtually no central technical management. There are groups of 2-4 developers who roam around their department's problem space, making whatever choices they want. If someone doesn't like the interface on one microservice, they fork the code and make a new one. This leads to 5 microservices that accomplish the same thing, and 5x the maintenance burden whenever something changes. I've derisively called these "nanoservices", but I need a more offensive term. People intentionally choose techs that no one else in the company has used, trying to cement their position and hedge up potential competition or unwelcome cooperation. They also select technology for the best PR effect, being able to say "We're being like Google today". The result is a whole mess of different stuff running throughout production, each needing its own backup system, etc., which, to be honest, does not always get installed. It's a disaster. The author's contention is that giving more choice to teams is better because it makes them feel more ownership in their product. That's fine, but do recognize that this is a psychological solution to a management problem. The job of the manager is to actively control the psychology of employees and the structure of the organization such that employees are happy to do things that lead to cooperation, not to allow employees to always get their way. Without a central coordinating force and everyone's acknowledgement that some compromise and sacrifice is necessary, everything falls apart quickly. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

dkhenry 10y ago
Conway's Law in your environment should probably be interpreted that you have a team that can't talk or work together at all. It has nothing to do with what technical choices they are making, even if you imposed a rigid technical structure you would still have divergent nanoservices because your team can't communicate.
- cookiecaper 10y ago
  No, it's not that they're incapable of working together. It's that they have no incentive to do so. They can do whatever they want now and improve their own positions by so doing, so why shouldn't they? Normally, people don't do this a) because they don't want to be required to deal with the cruft or b) because they believe someone will observe their bad behavior and stop it. They don't really have to deal with the cruft, and it's clear now that no one in this organization will hold them accountable, so why should they waste time and energy trying to build a consistent platform? re: Conway's Law, the organization's communication mechanisms are loose and ad-hoc; there is no central coordination. Consequently, the software is coordinated on a loose, ad-hoc basis between small teams. The same featureset will be implemented 4 times by 4 different teams, not because they can't talk (there is an office where most people hang out together all day, and people do generally keep an awareness of what the other group is working on), but because they'd rather just do it the way they want to do it. It's not that no one ever ends up sharing anything. It's just that instead of having a discussion and making consistent decisions about the platform, they just do what they want, because they can.

MaulingMonkey 10y ago

I don't have a choice: I must use a broad array of tools and languages. The gamedev stuff I've helped tackle fundamanetlaly required mostly C++... and a little C, and some x86/ARM/PPC for debugging, HLSL 3-5/GLSL ES/PSSL/<custom shader DSLs> for porting graphics, at least two shell scripting languages for CI servers (Bash, and Powershell or (ew!) Batch), Python (for various modeling tools)... Java, Objective C, and C++/CX for platform specific APIs... MSBuild, Makefiles, Gradle, Ant... and that's just the languages! The tooling front is no better. A handful more language choices that theoretically could've been avoided (e.g. C# for tools and server stuff, ActionScript for UI) is really not that big a deal in this context. You can add pointless layers of cruft, but I've only seen it once - a Python script used to hack up the result of a C++ program. Even then they had a reason: some of the C++ didn't get checked in, so we couldn't even build the C++ program. (A happy ending: With a little reverse engineering of the resulting binary output, I was able to re-implement the missing C++ bits, implement the Python-script 'fixes' more cleanly in the original C++, and add my own necessary changes on top of that.)

quantumhobbit 10y ago

Wow the comments here certainly seem to be against allowing developers any input in the tools they use. I guess you all are part of the reason I have to use Java 7 and outdated versions of Angular in my day job no matter their applicability to the problem domain and have no input in those decisions. I agree that total anarchy is bad in the workplace, but don't you think that the people using the tools should have some input in choosing the tools?

yawz 10y ago
I, for one, want to see something beyond the shiny-toy syndrome when I talk to a team member about why we need to use the tool/technology/framework/library in question. I'm all for personal improvement, and every technology, regardless how different it is, that we learn/become familiar with makes us better professionals. But sandbox to production is a long way. Keeping things simple has its merits.

Zigurd 10y ago

Choices break naturally on time and platform boundaries. New projects should review stack choices, and enforcing cross-platform stacks is usually too brittle.

nradov 10y ago

He seems to be ignoring long-term maintenance costs. If you're building a $0.99 app then sure let the team pick whatever they want. But if you're building a huge SaaS web application with an expected 20 year lifecycle then that cuts the range of sensible choices way down.