No matter what they tell you, it's a people problem (2008)
blog.codinghorror.com
blog.codinghorror.com
There is a category of problems that, I think, are mainly engineering problems (a few examples below.) You could argue that these, too, are people problems, because the team lacked experience and someone should have hired better engineers. However, given how difficult and unpredictable hiring is, I think it's better to treat questions of engineering design as primarily engineering problems, since that's a much easier problem to address. Some examples:
* An analytics system without tests that generated incorrect results silently.
* A project management system that ran out of memory when usage increased and couldn't be fixed without completely re-architecting it.
* An accounting system that wrote the same value in two places which frequently got out of sync.
I've noticed that test coverage and quality is largely a people (budget) problem. They want the system now. They want that value delivered number going up and the cycle time going down. Tests are some of the first cuts.
organizations spend a huge amount of resource keeping 'cicd' propped up, but when you look at whats inside - its a build, and some random unit tests and mocks.
to be fair, testing in an environment where everything is internal and external services laced together with json isn't easy. what i find really odd is just that no one is willing to acknowledge it as a real problem.
(And then those of us who care at least have the option of writing some tests. I'll take the heat for being "slower" if I have to, because a bare minimum of tests provides extremely high value and advocating for baseline CI/CD is a great way to contribute to any organization.)
If QA and engineering staff are organized into separate verticals, rather than being direct teammates that share a manager, then time that could have been spent on testing instead gets spent on bickering over who tests what and how.
If different team members have different opinions on testing strategy, and dig in on their respective positions rather than coming to an understanding, then tests will slip through the gap between them.
If senior team members don't think it's their responsibility to mentor (not browbeat!) less-experienced team members on good testing practice, then the correct tests won't get written.
If the people in charge of architecture don't recognize the outsize influence they have on the cost of designing and implementing tests, then testing can indeed become too expensive.
If people don't recognize that test cases are, first and foremost, a way of communicating and memorializing design specifications, and not just a clever way to run code in isolation, then the cost of maintaining them will go up and the value of maintaining them will go down, until people start to forget that there was ever a baby in all that bathwater in the first place.
etc.
Maybe this is the unofficial CTO creed or something.
No, but software engineers in aggregate have the memory and attention spans of goldfish.
Relearning again is the new learning again.
2000s: outsource to India rather than pay your people
2010s: hire cheap web devs out of school rather than pay your people
2020s:layoff everyone until something breaks, and certainly above all else, don't pay your people
2030sAAAAAAIIIIII wht have people at all
I've always been amazed at the kind of money companies will throw at not having to hire a developer. Salesforce is a quarter of a trillion dollar company because they tell management that they won't need to hire any developers and then charge outrageous rates to accomplish simple tasks in the most complicated way possible.
Just not yours, but their designated and certified developers that will stay stuck to Salesforce while your business might come and go. In the first few meetings with SF you'll invariably be presented with a consulting company that will help you deal with the purposedly hot mess that SF integration is.
Then the cycle restarts.
My father needed to design assembly lines that were safe enough for tweaked out workers who may not have slept for days to work on. Those were just his design constraints. True story.
God I wish the world was like this again. I know so many people that don't have jobs and can't land anything because there isn't enough open.
This very quickly becomes not the case due to the limited availability of... low hanging fruits.
This is of course not mentioned because why let reality get in the way of a good story.
Folks love a good fortune cookie - 'it's a people problem' - it only has 2 words! :)
I certainly agree that a lot of problems (including a lot of very difficult problems!) are not amenable to purely technical solutions.
But sometimes you have a difficult, technical bug to fix, and the "people problem" is making sure that someone has the knowledge, context, time, and incentive to fix it. This is not necessarily easy!
... especially if enough people have bought into "everything is a people problem", because then the technical work of fixing the bugs isn't valued or incentivized. Why would it be? It's not solving a people problem.
I think the viewpoint "everything is a people problem" can create a feedback loop that leads to poor incentives - which, ironically, is a people problem.
That's how you know the article is pure nonsense.
He wrote the questions back during the bad old days when a lot of shops tried to measure developer productivity in KLOCs.
Understanding the context, something similar today might be "How many story points will this take your team?" and if the answer is anything specific, the project is in trouble . . .
Hope it makes more sense to you now!
Nevertheless, this observation is too trivial to be useful, with the possible exception of "design things so that some automatic mechanism, independent of humans, is able to detect errors".
To the point of this article, the best product people were in fact respected by the tech team, and it made all the difference.
To design stuff. That's what engineers do (on the case of software, designing is also called "building" and "developing").
Engineers do not fix the problems of your organization. At least not while wearing an "engineer" hat.
> MBAs and project managers
Non-technical MBAs and project managers are patently unable to solve a lot of the organizational problems of engineering organizations. But well, usually yes, the MBAs are the ones tasked into solving them. I dunno why you included project managers.
Let's look at it as a bunch of people solving a problem which is too big for any one of them. Those people are different, they contribute different parts of the solutions - engineering, managerial - but they all have to cooperate to solve the problem, at least efficiently. If they don't, or don't do enough, for whatever reason, the solving suffers, possibly up to not happening.