Here's another quote: "You cannot improve that which you cannot measure." A corrolary would be that the only way you can measure is to make sure you're comparing apples to apples.
I love all the flame comments on these threads. Especially the assumption that management is stupid. Not that there isn't a reason for this perception, but the same perception exists that engineers/code monkeys are introverted trolls that never voice their opinions to management to help them make the right choice... Anyway, being in management myself, (but having been a code monkey for 10+ years) I can understand the viewpoint that many here are taking.
But that's not what I wanted to reply about. That was just my flame-bait! Really what I wanted to say is that I have a pretty good idea why the original poster's company is thinking about implementing a common tech stack. First, they have probably been burned by one or more of the following:
1. A critcal piece of their system is written in an obscure/unsupported language that no one at the company understands any more, and even though they are willing to invest in updating it, the $ required to basically stay par with existing functionality is causing some heartache.
2. A critical piece (or even non-critical) of their system has been found to have used a non-licensed or too restrictively licensed library that no one realized until just now, and they are facing legal risks unless they re-engineer it out of existence.
3. The company has grown quickly and people now realize that there are at least 3-5 different code repositories on different source control systems and no one really knows where certain pieces are or which repository has the "latest" deployed version.
4. Projects keep spending time writing and rewriting the same component multiple times, aka re-inventing the wheel.
5. "Key/core/irreplacable" engineers insist on promoting NIH (Not Invented Here) practices which people in the company are starting to realize come for free in certain modern environments.
6. In an existing product, the company released a service pack to customers, but as part of the work, an engineer upgraded a library/ide/runtime/etc which caused huge instability, and the QA team didn't catch it because they were assured that it was a very minor release.
I'm sure there are more, but those are 6 things off the top of my head that have happened to me both as an engineer and as a management-stooge type. And while a common tech stack doesn't eliminate these types of things from happening, they can help give better visibility into seemingly innocuous choices that engineers make almost every day.
Most policies like this are because something bad has happened somewhere in the company and people are trying to limit future exposure to risk. Now, I'm sure as you're reading this post you're thinking that you are a damn fine engineer and these things would never happen to you. And maybe you're right, but are you better than the other people that are reading this post? While I'm sure that you are surely God's gift to the engineering world, not everyone in the engineering world is. People make mistakes. Maybe even you.
These kinds of initiatives aren't necessarily all bad if they aren't implemented in strict black and white. If they are used as guidelines that can be bent and broken for the right reasons, then it can be very beneficial. Even that process of getting permission to go outside the guidelines can cause good dialog to occur that can result in an even better idea to bubble up.
Whew. That was more than I intended to type. Go ahead and rip me apart now.
Slashdot Mirror
Here's another quote: "You cannot improve that which you cannot measure."
A corrolary would be that the only way you can measure is to make sure you're comparing apples to apples.
I love all the flame comments on these threads. Especially the assumption that management is stupid. Not that there isn't a reason for this perception, but the same perception exists that engineers/code monkeys are introverted trolls that never voice their opinions to management to help them make the right choice...
Anyway, being in management myself, (but having been a code monkey for 10+ years) I can understand the viewpoint that many here are taking.
But that's not what I wanted to reply about. That was just my flame-bait! Really what I wanted to say is that I have a pretty good idea why the original poster's company is thinking about implementing a common tech stack. First, they have probably been burned by one or more of the following:
1. A critcal piece of their system is written in an obscure/unsupported language that no one at the company understands any more, and even though they are willing to invest in updating it, the $ required to basically stay par with existing functionality is causing some heartache.
2. A critical piece (or even non-critical) of their system has been found to have used a non-licensed or too restrictively licensed library that no one realized until just now, and they are facing legal risks unless they re-engineer it out of existence.
3. The company has grown quickly and people now realize that there are at least 3-5 different code repositories on different source control systems and no one really knows where certain pieces are or which repository has the "latest" deployed version.
4. Projects keep spending time writing and rewriting the same component multiple times, aka re-inventing the wheel.
5. "Key/core/irreplacable" engineers insist on promoting NIH (Not Invented Here) practices which people in the company are starting to realize come for free in certain modern environments.
6. In an existing product, the company released a service pack to customers, but as part of the work, an engineer upgraded a library/ide/runtime/etc which caused huge instability, and the QA team didn't catch it because they were assured that it was a very minor release.
I'm sure there are more, but those are 6 things off the top of my head that have happened to me both as an engineer and as a management-stooge type. And while a common tech stack doesn't eliminate these types of things from happening, they can help give better visibility into seemingly innocuous choices that engineers make almost every day.
Most policies like this are because something bad has happened somewhere in the company and people are trying to limit future exposure to risk. Now, I'm sure as you're reading this post you're thinking that you are a damn fine engineer and these things would never happen to you. And maybe you're right, but are you better than the other people that are reading this post? While I'm sure that you are surely God's gift to the engineering world, not everyone in the engineering world is. People make mistakes. Maybe even you.
These kinds of initiatives aren't necessarily all bad if they aren't implemented in strict black and white. If they are used as guidelines that can be bent and broken for the right reasons, then it can be very beneficial. Even that process of getting permission to go outside the guidelines can cause good dialog to occur that can result in an even better idea to bubble up.
Whew. That was more than I intended to type. Go ahead and rip me apart now.