the author does make some good points, but I was a bit taken aback by the whole "who could possibly get excited about logistics of all things?!" bit. makes me wonder what else he simply doesn't "get" because he has written entire areas off as intrinsically boring and lacking in value.
The Failed Commodification of Technical Work
171–180 of 210 posts
Re: The Failed Commodification of Technical Work
#172Earlier quoted context omitted.
The entirety of the Phoenix project is literally just copying Goldratt's the goal and then doing a s/manufacturing/IT/g and updating the references to modern day. I'm not saying I don't like it, I've read the book half a dozen times and try and get every team I'm on to read it to help modify their thinking to be more systems focused, but I'm not going to pretend that it much deeper or insightful than the goal.
I feel I have to respond to this, as the Phoenix Project is probably the cringiest book I ve read in my life, and I've read The Effective Executive... I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda. My biggest problem with the book is the same problem I have with sc…
> I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda.
I enjoyed the book personally. I think the key point it was trying to get across is that of all the things that look like "common sense" to people, the combination of these particular things is what is actually effective. it was never about blindly following some magic recipe, simply "here is a way of thinking about the overall task of project management that may be helpful, and here are some specific techniques that support it".
note that "if the project is behind we should make the engineers work 12 hours a day instead of 8" is common sense to a very large percentage of managers.
Re: The Failed Commodification of Technical Work
#173I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…
the people you're supposed to be eliciting requirements from are just regurgitating what ChatGPT told them are the requirements hehehe
Re: The Failed Commodification of Technical Work
#174I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…
the people you're supposed to be eliciting requirements from are just regurgitating what ChatGPT told them are the requirements hehehe
This is becoming so true. I have read so many documents in the last year that are obviously from a GPT, especially when it’s about something new to a group.
But in the end, I would rather get a half baked GPT doc than a quarter baked junior analyst doc. I just worry that GPTs are going to kick the rungs out of the bottom of any knowledge work later. Being bad but junior used to be a learning environment without too many repercussions.
But how do you compete with peers using AI? You use it also. But now you have robbed yourself of a learning opportunity. Yeah you can learn someway by doing it, but it’s like doing homework by looking at the answers. Sure it can help you double check, but if you don’t put the effort into constructing your own answer, then you have only cheated yourself.
I think the AI alignment issues are probably over blown in the short term, but what about the long term when the average person has regressed so far as to be unable to live without AI. They will just do whatever is told to them.
Re: The Failed Commodification of Technical Work
#175Earlier quoted context omitted.
Open source is great, Lazarus does a pretty good job of replacing Delphi. Microsoft went insane with .NET so VB6 was killed in the process. Access automatically handled table relationships, building queries and seeing them as SQL, and the report engine was pretty good. Thanks to ODBC, you could use the same database across all of them, or hook up to a real SQL server when it came time to scale up. What's missing is t…
> Microsoft went insane with .NET so VB6 was killed in the process. I'd love to hear more about this perspective or any links to get more of it. I did a (very) little hobby VB6 and loved it. Never made switch to .NET at that time (I was young, it was a hobby). Having recently worked through part of a .NET book, I was pretty impressed by how far MS took it (although it seems extremely mind-numbing). Obviously it took…
Disclaimer: I am not a .Net programmer, so these are just my thoughts and impressions as someone on the outside who followed the development from a distance.
I think a lot of the focus on .Net was driven by MS and Balmer's fear of Java. At the time, almost all desktop computers were running Windows 9x/2k. If 3rd party applications were developed with cross-platform Java, the customers would no longer be locked in to Windows.
First they tried the famous embrace/extend/extinguish approach by creating a Windows-specific version of Java. Sun fought back, and MS decided to push .Net instead.
It seemed to me that the initial strategy was to claim .Net was cross platform, but focus more on Windows and let open source projects like Mono be their cross platform "alibi". They changed strategies after a while, and now I guess the cross platform is more real.
Re: The Failed Commodification of Technical Work
#176Earlier quoted context omitted.
> hating most of Scrum I'll just say that if you look at Scrum itself there is really nothing objectionable to it. https://scrumguides.org/scrum-guide.html It's the other shit people pack on top of calling it Scrum that usually sucks ass. I've found the best way to fight back against shitty-Scrum is not to fight it, but actually feign puritanical allegiance to the actual doctrine, it's much less repulsive. I makes yo…
The naming of the time blocks as "Sprints" is objectionable. Let me just _sprint_ 20 times back to back in a year, year on year for my whole career!
Hard agree, the naming of much of Agile/Scrum is terrible from the dev perspective.
Re: The Failed Commodification of Technical Work
#177Earlier quoted context omitted.
I feel I have to respond to this, as the Phoenix Project is probably the cringiest book I ve read in my life, and I've read The Effective Executive... I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda. My biggest problem with the book is the same problem I have with sc…
> I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda. I enjoyed the book personally. I think the key point it was trying to get across is that of all the things that look like "common sense" to people, the combination of these particular things is what is actually effec…
I don't know, to me, that was not literature, but a guidebook with examples.
Here is Bill, he's tired and overworked. If only he can focus on the important tasks and clear the clutter...
Here is Security guy. He is grumpy and is in a war with the developers because they don't follow his ancient and unworkable security practices. if only he could update his security practices to something more modern and cool.
Here is Maxine. She is a PO. Her team is given task after task and not allowed to focus. If only Maxine could protect her team from outside influence...
Here is CEO guy. His company is failing and he is trigger happy on ever changing initiatives and transformations, and nothing comes to fruition. IF only he could chart the course for his team, set performance metrics, and not change direction every 15 seconds...
Here is operations linux admin guy. He has a bunch of scripts that make the deploys when devs throw some new garbage over the fence to him. He is mad because the devs wrote yet another service in yet another language, making the ratio of devs to languages used 10 to 17. If only he and the devs could agree on a deployment standard or read about the wonders of k8s...
If this kind of preachy obvious rhetoric inspires somebody to take a deep hard look at themselves, recognize their flaws, and change, more power to them. However, I am simply allergic to patronizing narratives like this.
> note that "if the project is behind we should make the engineers work 12 hours a day instead of 8" is common sense to a very large percentage of managers.
Then out with managers like that. Most engineers can do their job without a pencil pusher standing over their shoulder and trying to "manage" them. However, there are only few managers who actually can do anything useful without underlings...
Re: The Failed Commodification of Technical Work
#178Earlier quoted context omitted.
> that software development labor would be fully itemized in a standard catalogue like auto mechanic by the year 2000. That's pretty dumb... Software doesn't "break" and if it could be itemized to such a degree it could be made self-healing.
> Software doesn't "break" It most certainly does because most software is written atop dynamic systems and every possible change cannot be pre-empted. Extreme example: RAM writes accidentally flipping bits ala RowHammer. Broken, yes, but is it a bug?
I'd still describe the first one as "non-line-item-able" how can you set a lineitem time to "re-jigger the dependencies"? Those take open-ended investigation that no experienced "dev" would commit small amounts of time to like replacing the alternator in a 2003 Ford Ranger.
The second one is clearly an automation issue, are you going to assign a lineitem to "fix the latest rowhammer attack"?
Re: The Failed Commodification of Technical Work
#179This post resonates with me as a radiologist with 40 years experience, and a son who founded and runs his own company centered around machine learning, and now, LLMs. I frequently hear about how "AI" is going to replace radiologists any day now, but I do not believe it, for some of the same reasons described by the author, though in a different context.
I recently wrote a post "Will Artificial Intelligence Replace Radiologists": https://anordinarydoctor.substack.com/p/will-artificial-inte... that explains why I think the answer is "Yes, when it replaces engineers and everybody else".
Re: The Failed Commodification of Technical Work
#180Earlier quoted context omitted.
> I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda. I enjoyed the book personally. I think the key point it was trying to get across is that of all the things that look like "common sense" to people, the combination of these particular things is what is actually effec…
I don't know, to me, that was not literature, but a guidebook with examples. Here is Bill, he's tired and overworked. If only he can focus on the important tasks and clear the clutter... Here is Security guy. He is grumpy and is in a war with the developers because they don't follow his ancient and unworkable security practices. if only he could update his security practices to something more modern and cool. Here is…
it was literally meant to be a guidebook with examples. I found that an entertaining way to present the material - if you were looking for literature or subtlety I can see why you would have found it patronising but personally I didn't feel talked down to when I read it.