4 ms·

One of the core reasons software projects run into problems is politics - and this article is about politics. What should have happened ideally is that the blo

One of the core reasons software projects run into problems is politics - and this article is about politics. What should have happened ideally is that the blog post author would have said to the CTO: - we're going with React - you've chosen us to guide you in this - you now need to trust that my advice on standards and approach is correct - you need to get your developers to do it the way I say - if you don't, then we will be building a frankenstein React project which is built like a .NET application - the success of the project is at risk And the CTO would have been wise enough to agree and pull his people into line and give the blog post author the authority to demand things be done as he says they should be done. But that's politics and hard to do.

scsilver 6y ago
Politics is the game of making incremental progress and always feeling like you left something on the table, its such and opposite skill of engineering, and yet it is the most important skill in engineering useful systems.
worik 6y ago
"- you need to get your developers to do it the way I say" You have a team of developers that have a collective experience of perhaps eighty years in your organisation. Do as I say, me who just popped in and afterwards will pop out again.... That is how millions and millions of dollars are lost in this business.
- andrewstuart 6y ago
  If a CTO engages an external company to lead them into a project using new technologies for that team, then that CTO would be well advised to accept that their supplier has the right knowledge to advise them.
- d0100 6y ago
  Just like Riot has 200 years of experience doing their game and shit still hits the fan on a timely basis
erlich 6y ago
The problem is that the author most probably chose some libraries than went out of fashion or started stagnating and ran into some bugs or lack of documentation that drained time. Its impossible in JS to not have made bad choices that didn't last or cost huge amounts of dev time to workaround. The real key to politics is building up enough political capital to be able to survive when things go south. If you continuously make bad decisions you will inevitably be fired. Even if you were always learning from them each time. I would say: - communication - here is why and how we made these decisions and the assumptions we followed. if they turn out to be bad choices, here is where our assumptions were wrong. we are going to learn from them in the future. - management buy-in - you need the CTO to buy into your decisions and reasons and not just to trust you to make them. let them make the decision. avoids the blame game in the future. - avoid shiny things - you have to stick with what you chose and focus on delivering business value rather than always thinking about that re-write or the new shiny thing. work is going to be less fun and you will feel like saying "a rewrite to this library is going to make us more productive" but it rarely will and unless you have a strong CTO its always going to be hard to justify.
sli 6y ago
I've had clients where this would get you told (in execuspeak) that the least important part of a project is the engineering and the engineering team. Which is of course why their sales people would answer every question with, "Yep, it does that." Nevermind that some of the things getting promised were not actually possible. I remember one in particular that would push incredibly tight deadlines for huge features, got frustrated at the pace and hired another dev team, and didn't change the way they set deadlines. This of course fixed nothing. Then the other team they hired pushed a huge change to the repo, almost every file in the codebase was touched. Nearly 70% of which was whitespace changes and the other 30% was unfinished code that did not compile. We later found evidence that they hadn't even run the code before pushing the changes. The client demanded that we merge it, were told it would break the build, got mad when we merged it and the build broke, then tried to use that (and a whole bunch of almost hilarious and similarly-effective arguments) against us in a lawsuit which they lost, and then lost the countersuit. So yeah, that was a fun time for my liver, to say the least. Especially since the C-levels decided to focus the entire company's output on that lawsuit while the engineering team sat around mostly twiddling their thumbs.

scsilver 6y ago

Politics is the game of making incremental progress and always feeling like you left something on the table, its such and opposite skill of engineering, and yet it is the most important skill in engineering useful systems.

worik 6y ago

"- you need to get your developers to do it the way I say" You have a team of developers that have a collective experience of perhaps eighty years in your organisation. Do as I say, me who just popped in and afterwards will pop out again.... That is how millions and millions of dollars are lost in this business.

andrewstuart 6y ago
If a CTO engages an external company to lead them into a project using new technologies for that team, then that CTO would be well advised to accept that their supplier has the right knowledge to advise them.
d0100 6y ago
Just like Riot has 200 years of experience doing their game and shit still hits the fan on a timely basis

erlich 6y ago

The problem is that the author most probably chose some libraries than went out of fashion or started stagnating and ran into some bugs or lack of documentation that drained time. Its impossible in JS to not have made bad choices that didn't last or cost huge amounts of dev time to workaround. The real key to politics is building up enough political capital to be able to survive when things go south. If you continuously make bad decisions you will inevitably be fired. Even if you were always learning from them each time. I would say: - communication - here is why and how we made these decisions and the assumptions we followed. if they turn out to be bad choices, here is where our assumptions were wrong. we are going to learn from them in the future. - management buy-in - you need the CTO to buy into your decisions and reasons and not just to trust you to make them. let them make the decision. avoids the blame game in the future. - avoid shiny things - you have to stick with what you chose and focus on delivering business value rather than always thinking about that re-write or the new shiny thing. work is going to be less fun and you will feel like saying "a rewrite to this library is going to make us more productive" but it rarely will and unless you have a strong CTO its always going to be hard to justify.

sli 6y ago

I've had clients where this would get you told (in execuspeak) that the least important part of a project is the engineering and the engineering team. Which is of course why their sales people would answer every question with, "Yep, it does that." Nevermind that some of the things getting promised were not actually possible. I remember one in particular that would push incredibly tight deadlines for huge features, got frustrated at the pace and hired another dev team, and didn't change the way they set deadlines. This of course fixed nothing. Then the other team they hired pushed a huge change to the repo, almost every file in the codebase was touched. Nearly 70% of which was whitespace changes and the other 30% was unfinished code that did not compile. We later found evidence that they hadn't even run the code before pushing the changes. The client demanded that we merge it, were told it would break the build, got mad when we merged it and the build broke, then tried to use that (and a whole bunch of almost hilarious and similarly-effective arguments) against us in a lawsuit which they lost, and then lost the countersuit. So yeah, that was a fun time for my liver, to say the least. Especially since the C-levels decided to focus the entire company's output on that lawsuit while the engineering team sat around mostly twiddling their thumbs.