Tech is time, time is money.
There always an ajustement tech-money.
You can't promoting new tech or refactoring without looking contingencies.
What you need is just a circular graph. Who can be a vicious circle or a virtuous cycle, depending who is in charge.
This usually shows up in the late game of successfull companies. Suddenly new products are slow.
Exponential numbers of people have to be hired.
Some parts cant be worked on if one member of the company is on holiday.
I recommend reading The Mythical Man Month[1] to anyone interested in proper SWE project management. There are so many wannabe managers out there that will just through more people at a project which is slowing down.
To quote the book: "Adding manpower to a late software project, makes it later". There's some really good stuff in there, even for those of us that are less interested in management.
I keep recommending it to my younger colleagues but they just make polite noises and forget it.
Some of Brooks' suggestions for the make up of a development team are interesting. In particular I have always liked the idea that there should be a toolmaker. Most of us are less efficient than we could be because we lack specific tools to do the job and we don't personally have time to make them. If we had someone who's only job was to make tools I think a lot of things could go faster. Of course this only applies to moderately large teams.
I'm my team's toolmaker. There's just so much lost opportunity in custom tools doing repetitive tasks, it's strange that you would leave that on the table.
But I'm not getting paid for it, my manager doesn't order it. He's kind of happy to see us getting more efficient with less bugs. But it would be good to have some support.
Imagine you're a CEO, or VP sales, or anyone with responsibility for moving the company forward. Lets say you have a technical background and actually understand how bad things can get with a codebase.
Its year 2 and you're desperate to ramp sales. the company is in existential crisis, the end of the runway is approaching rapidly. The product ostensibly works, but there are lots of customer problems and new feature requests always seem to get bogged down.
Your technical leaders say that the product has driven into a swamp, and you need 2 months to dig it out, plus 30% overhead ongoing to finish the cleanup and try to keep on the straight and narrow.
Even though its the right thing to do in some world, how likely are you to say 'I understand, take all the time you need, we don't want these problems plaguing us'
37signals wrote a book on this a decade ago before they changed their name to Basecamp. It is loaded with practical advice on how to build good software and avoid technical debt.
IME this is why some new companies are extremely choosy with hires for a long time. The newer/smaller the company, the less time there is available for oversight of each other's work. That is not to say zero review happens, but if you're trying to move fast, trust and confidence in what the rest of the team is doing facilitates that.
This may sound overly negative or controversial, but I think there are a lot of tech workers out there that are technical debt factories. They'll produce highly coupled code, super long functions, inefficient code, etc...and be extremely defensive during code review. The mantra you'll hear from this person is, "but it works!" - which is exactly what the PM will hear.
So it gets shipped. After this happens enough, "simple" changes to the product that should be easy to produce, aren't so simple.
11 comments
[ 5.7 ms ] story [ 64.8 ms ] threadTo quote the book: "Adding manpower to a late software project, makes it later". There's some really good stuff in there, even for those of us that are less interested in management.
[1]: https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...
Some of Brooks' suggestions for the make up of a development team are interesting. In particular I have always liked the idea that there should be a toolmaker. Most of us are less efficient than we could be because we lack specific tools to do the job and we don't personally have time to make them. If we had someone who's only job was to make tools I think a lot of things could go faster. Of course this only applies to moderately large teams.
But I'm not getting paid for it, my manager doesn't order it. He's kind of happy to see us getting more efficient with less bugs. But it would be good to have some support.
Its year 2 and you're desperate to ramp sales. the company is in existential crisis, the end of the runway is approaching rapidly. The product ostensibly works, but there are lots of customer problems and new feature requests always seem to get bogged down.
Your technical leaders say that the product has driven into a swamp, and you need 2 months to dig it out, plus 30% overhead ongoing to finish the cleanup and try to keep on the straight and narrow.
Even though its the right thing to do in some world, how likely are you to say 'I understand, take all the time you need, we don't want these problems plaguing us'
37signals wrote a book on this a decade ago before they changed their name to Basecamp. It is loaded with practical advice on how to build good software and avoid technical debt.
Aside: no affiliation, just a fan of the book.
This may sound overly negative or controversial, but I think there are a lot of tech workers out there that are technical debt factories. They'll produce highly coupled code, super long functions, inefficient code, etc...and be extremely defensive during code review. The mantra you'll hear from this person is, "but it works!" - which is exactly what the PM will hear.
So it gets shipped. After this happens enough, "simple" changes to the product that should be easy to produce, aren't so simple.