4 ms·

I generally agree with your post, but I think there is a critical difference between your argument and that of the blog post. Of course teams are more productiv

by shebson 12y ago

I generally agree with your post, but I think there is a critical difference between your argument and that of the blog post. Of course teams are more productive with technologies they know, but that isn't necessarily an arbitrarily-defined "boring" technology. To pick on one specific example in the post: Node.js is popular enough that there are lots of teams and engineers that are most comfortable and productive working with it. For these teams, choosing Node certainly wouldn't cost an innovation token, while deciding to build some service in Python, Ruby or PHP (if we take at face value that this is more "boring") may end up being more costly.

fineline 12y ago
Yep, what's "innovative" for one person or team is "boring" for another, and vice versa. NodeJS / PHP is a good example.
wdewind 12y ago
> For these teams, choosing Node certainly wouldn't cost an innovation token, while deciding to build some service in Python, Ruby or PHP (if we take at face value that this is more "boring") may end up being more costly. It absolutely does if it is only one team in the organization. If the entire organization is using PHP and, let's say, you acqui-hire a team based on NodeJS, unless they are doing something absolutely fundamentally different they should learn PHP and push code in your existing infrastructure. This way you have one way to deploy, one type of application server to support, one set of gotchas relevant to your domain, one set of QA tools etc. Building good products is about far more than just shipping the product, it's also about the cost of long term support. Because what you are doing is fundamentally automation, the less you have to manage the more benefit of the automation you are getting, the more you can forget about it and focus on shipping other things. What you are describing is pretty much definitionally local optimization and is exactly what you shouldn't do in large engineering organizations.
- mentat 12y ago
  Depends on your increment of isolation. This is, in theory, why microservices with APIs mean that it really doesn't matter. As long as there are sufficient hire-able engineers who know that technology, it can be used.
  - wdewind 12y ago
    > This is, in theory, why microservices with APIs mean that it really doesn't matter. No it still really does matter, because if your company needs to deploy those microservices in different ways then you need more people to support the deployment infrastructure. If you need to test those microservices in more ways you need more people to support the testing infrastructure. For engineers it's the amount of friction felt when trying to move around and work on new and different problems in your company because they're one of five people who knows how the hell the Java infrastructure works. If you have an existing testing and deployment infrastructure etc. your team gets those for free and doesn't need to reinvent (and support) those wheels. > As long as there are sufficient hire-able engineers who know that technology, it can be used. Yikes. Hiring and firing engineers is pretty hugely expensive and something you want to help avoid having to do.
    - jacques_chester 12y ago
      > No it still really does matter, because if your company needs to deploy those microservices in different ways then you need more people to support the deployment infrastructure. This is what PaaSes make a non-problem. I should know, I worked on Cloud Foundry Buildpacks. Here's how to deploy the PHP app: cf push your-php-app And the Nodejs app: cf push your-nodejs-app And hell, why not a Ruby app too: cf push your-ruby-app And let's not forget that Python microservice: cf push python-code-works-the-same-way We also kept up with the cool kids: cf push your-go-code-with-a-godeps-file And for the "boring" crowd: cf push your-java-app-too In general, these are all intended to Just Work™. You know how making these surprisingly unalike systems deploy identically is really hard? So does Heroku, from whom a large body of Cloud Foundry buildpacks code is derived. So did we, when we found issues specific to making code that assumes a connected environment work in a disconnected environment. The point is, if you're doing this all by hand, you're doing it wrong. You should rent or install a PaaS and move along to the part where you create value instead of inventing a cool-sounding wheel.
- curun1r 12y ago
  > It absolutely does if it is only one team in the organization. If the entire organization is using PHP and, let's say, you acqui-hire a team based on NodeJS, unless they are doing something absolutely fundamentally different they should learn PHP and push code in your existing infrastructure. Substitute PHP with Java, and you've described the situation at my company exactly. The acquiring company had a legacy Java application and a lot of automation invested in making that platform work. The acquired company was a NodeJS shop that was using it long before this article or the comments in this thread would advise (this was pre-npm days). To give you an idea of the numbers, the acquired team was 4 engineers as compared to the 100 engineers of the acquiring company (50/50 split with an off-shore development team). I won't say which side of that divide I was on or go into the full year of culture shock that we went through, but fast forwarding these past 4+ years and now the bulk of the company's main product has been re-written in Node and developers are significantly more productive. Features that used to take months to push out in complex releases using a convoluted process of branching, meetings and tons of arguments are now delivered continually using the Github flow with little-to-no drama and far fewer production bugs/downtime. Our customers have never been happier with us and developers have never been happier to work here. All of this came from the fact that the CMO who advocated for the acquisition supported the small team of 4 in every effort to pervade the small team's technologies and practices across the larger organization. Having been in organizations that performed at a much higher level, he recognized just how much opportunity there was for improvement and recognized that the team of 4 had the vision to create the necessary blueprint for the rest of the organization to follow. It wasn't easy, and most of the developers who were here at the beginning of the shift are no longer part of the company. But it worked...and while a sample size of one is hardly conclusive, I have a hard time agreeing with your point having seen it play out so well in the real world.
  - devonkim 12y ago
    I've been on both sides of this very important scenario that truly does matter for this industry (the failure rate of acquisitions is hardly as well known as start-up failures when the amount of dollars wasted - oftentimes publicly traded - is probably larger on these sunk costs), and the VAST MAJORITY of acquisitions result in the larger company overriding the smaller with basically just existing customers sticking around out of little choice and almost everyone disappearing (Palm and HP, anyone?). Do you think a company of 4 being acquired would be able to as dramatically affect a company of 200 engineers? How about 2000? What if the engineers aren't even in charge of the platforms they're required to use? (It's literally defined by what your customers want, for example, in a hosted software shipping company) I am not doubting that your scenario happens, but the possibility of changing a team of 100 (likely pretty jaded) engineers while certainly difficult is not necessarily what people think of when we're thinking acqui-hire. In fact, I'm barely entering my second decade as an engineer and I'm starting to think that surviving an acquisition intact and with career advancement somehow is probably far more lucky than hitting a start-up lottery jackpot in the first place. There's gotta be a sort of trend of engineers that have gotten acquired so many times that their specialty now is to be able to scale / re-focus technology stacks and integrate and operationalize them better for other companies. Start-up companies typically want to see engineers that have a history of building stuff fast, growing rapidly, and the usual stuff that people get glory for as engineers. Established companies really aren't as picky. There's so many companies getting acquired you'd think that there's a niche for transitioning software over by now at least as contracting gigs.

by shebson 12y ago

fineline 12y ago

Yep, what's "innovative" for one person or team is "boring" for another, and vice versa. NodeJS / PHP is a good example.

wdewind 12y ago

> For these teams, choosing Node certainly wouldn't cost an innovation token, while deciding to build some service in Python, Ruby or PHP (if we take at face value that this is more "boring") may end up being more costly. It absolutely does if it is only one team in the organization. If the entire organization is using PHP and, let's say, you acqui-hire a team based on NodeJS, unless they are doing something absolutely fundamentally different they should learn PHP and push code in your existing infrastructure. This way you have one way to deploy, one type of application server to support, one set of gotchas relevant to your domain, one set of QA tools etc. Building good products is about far more than just shipping the product, it's also about the cost of long term support. Because what you are doing is fundamentally automation, the less you have to manage the more benefit of the automation you are getting, the more you can forget about it and focus on shipping other things. What you are describing is pretty much definitionally local optimization and is exactly what you shouldn't do in large engineering organizations.

mentat 12y ago
Depends on your increment of isolation. This is, in theory, why microservices with APIs mean that it really doesn't matter. As long as there are sufficient hire-able engineers who know that technology, it can be used.
- wdewind 12y ago
  > This is, in theory, why microservices with APIs mean that it really doesn't matter. No it still really does matter, because if your company needs to deploy those microservices in different ways then you need more people to support the deployment infrastructure. If you need to test those microservices in more ways you need more people to support the testing infrastructure. For engineers it's the amount of friction felt when trying to move around and work on new and different problems in your company because they're one of five people who knows how the hell the Java infrastructure works. If you have an existing testing and deployment infrastructure etc. your team gets those for free and doesn't need to reinvent (and support) those wheels. > As long as there are sufficient hire-able engineers who know that technology, it can be used. Yikes. Hiring and firing engineers is pretty hugely expensive and something you want to help avoid having to do.
  - jacques_chester 12y ago
    > No it still really does matter, because if your company needs to deploy those microservices in different ways then you need more people to support the deployment infrastructure. This is what PaaSes make a non-problem. I should know, I worked on Cloud Foundry Buildpacks. Here's how to deploy the PHP app: cf push your-php-app And the Nodejs app: cf push your-nodejs-app And hell, why not a Ruby app too: cf push your-ruby-app And let's not forget that Python microservice: cf push python-code-works-the-same-way We also kept up with the cool kids: cf push your-go-code-with-a-godeps-file And for the "boring" crowd: cf push your-java-app-too In general, these are all intended to Just Work™. You know how making these surprisingly unalike systems deploy identically is really hard? So does Heroku, from whom a large body of Cloud Foundry buildpacks code is derived. So did we, when we found issues specific to making code that assumes a connected environment work in a disconnected environment. The point is, if you're doing this all by hand, you're doing it wrong. You should rent or install a PaaS and move along to the part where you create value instead of inventing a cool-sounding wheel.
curun1r 12y ago
> It absolutely does if it is only one team in the organization. If the entire organization is using PHP and, let's say, you acqui-hire a team based on NodeJS, unless they are doing something absolutely fundamentally different they should learn PHP and push code in your existing infrastructure. Substitute PHP with Java, and you've described the situation at my company exactly. The acquiring company had a legacy Java application and a lot of automation invested in making that platform work. The acquired company was a NodeJS shop that was using it long before this article or the comments in this thread would advise (this was pre-npm days). To give you an idea of the numbers, the acquired team was 4 engineers as compared to the 100 engineers of the acquiring company (50/50 split with an off-shore development team). I won't say which side of that divide I was on or go into the full year of culture shock that we went through, but fast forwarding these past 4+ years and now the bulk of the company's main product has been re-written in Node and developers are significantly more productive. Features that used to take months to push out in complex releases using a convoluted process of branching, meetings and tons of arguments are now delivered continually using the Github flow with little-to-no drama and far fewer production bugs/downtime. Our customers have never been happier with us and developers have never been happier to work here. All of this came from the fact that the CMO who advocated for the acquisition supported the small team of 4 in every effort to pervade the small team's technologies and practices across the larger organization. Having been in organizations that performed at a much higher level, he recognized just how much opportunity there was for improvement and recognized that the team of 4 had the vision to create the necessary blueprint for the rest of the organization to follow. It wasn't easy, and most of the developers who were here at the beginning of the shift are no longer part of the company. But it worked...and while a sample size of one is hardly conclusive, I have a hard time agreeing with your point having seen it play out so well in the real world.
- devonkim 12y ago
  I've been on both sides of this very important scenario that truly does matter for this industry (the failure rate of acquisitions is hardly as well known as start-up failures when the amount of dollars wasted - oftentimes publicly traded - is probably larger on these sunk costs), and the VAST MAJORITY of acquisitions result in the larger company overriding the smaller with basically just existing customers sticking around out of little choice and almost everyone disappearing (Palm and HP, anyone?). Do you think a company of 4 being acquired would be able to as dramatically affect a company of 200 engineers? How about 2000? What if the engineers aren't even in charge of the platforms they're required to use? (It's literally defined by what your customers want, for example, in a hosted software shipping company) I am not doubting that your scenario happens, but the possibility of changing a team of 100 (likely pretty jaded) engineers while certainly difficult is not necessarily what people think of when we're thinking acqui-hire. In fact, I'm barely entering my second decade as an engineer and I'm starting to think that surviving an acquisition intact and with career advancement somehow is probably far more lucky than hitting a start-up lottery jackpot in the first place. There's gotta be a sort of trend of engineers that have gotten acquired so many times that their specialty now is to be able to scale / re-focus technology stacks and integrate and operationalize them better for other companies. Start-up companies typically want to see engineers that have a history of building stuff fast, growing rapidly, and the usual stuff that people get glory for as engineers. Established companies really aren't as picky. There's so many companies getting acquired you'd think that there's a niche for transitioning software over by now at least as contracting gigs.