Agreed. This is like blaming the user for your bad UX. Nope, the solution increased the complications of a very complex problem set (scaling software development).
There are no silver bullets that can solve this. Only well-designed systems accommodate for the flexibility of human error and hubris can do that.
Yeah, it is a bit of a blanket statement, and it's quite common to headline with provocation, but there are some good things in here. He admits upfront that MS is his personal preference.
> I understand it’s a harsh title and at times a harsh essay. Such is life. All opinions are my own.
Some takeaways you might have missed:
* Use the right tool for the job - one-tool shops are bound to fail
* (Similar to above) There is a tendency to find _a_ solution rather than the _optimal_ solution
* The engineering halo effect is real and prominent
Then the author goes on to provide some possible solutions:
* Using the SOLID framework for building
* Use services
* KISS
* Developer experience is very important
* Protect your time and your work
* Governance is required to enforce certain principals.
I don't agree with all of these, but they are certainly worth considering.
I did find that lots of people who disliked it, mainly just got put off by the overall tone and the provocative statements from the get go. I basically blame my writing skills (and maybe personality haha). This essay lacks structure and it's more of a stream of thought (sometimes jumping all over the place and going off topic).
> But the attitude that "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers" is a naive attitude.
It's even worse than naïve, it's a literal fallacy, a "No true Scotsman" with technology.
System resilience is important at scale, and resilience includes being resilient to the failures in the human component of development; if a system depends that every one developing it to be a master of the underlying foundation then you'll require lots of very specialised, competent people who mastered the technique. That is very costly, if microservices depend on high mastery then we should budget the cost of the talented people required to run it.
My experiences with how to successfully deploy microservices include much the opposite: giving tooling to incompetent people to avoid the worst footguns, training them in best practices over time while designing an architecture that is somewhat resilient to their inevitable failures, one that is easy to be fixed when they've learned how to best use it.
> "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers"
And even in those 9/10 companies, the failure doesn't even prove that the engineers are the ones unable to create meaningful service boundaries, within a monolith or distributed to multiple services. All of those engineers have bosses and, I don't know what others are seeing, but I feel like I've seen Software Development Manager increasingly become Manager of Software Developers.
I suggest that those same management structures which failed to enable their engineers to create meaningful service boundaries in their monolith, which led to the desire for a cure-all solution, also failed to manage (or protect) their developers such that those developers _could_ turn the existing system architecture into one based on microservices.
Technical leadership has just become increasingly abysmal. Developers are tasked to fulfill user stories but those are often written in a way that completely ignores the technical work required to fulfill such a story. That creates a painful disconnect between expectations and reality, even in 90% CRUD, monolith web apps. Even in a monolith with proper separation of concerns, its easy to imagine one service being the "user" of another service for the purpose of more granular and clear tasks but, "that's not how user stories work." :(
Bingo. Design for incompetence. There are few codebases in this world that don't need incompetent people to contribute to them. (This is typically driven by business incentives)
If you get to work on one of those codebases ... good for you. The rest of us are just trying to gatekeep piles of shit from getting in while being pushed by management to open the flood gates.
There are a lot of things in life that would be trivial if everyone was really good at what they did, had the most perfectly pure of intentions, and were omnisciently aware. Unfortunately that’s not the world we live in, and even farther from the companies most of us work for. Good technology is about figuring out shortcuts around hard problems, and “large groups of people trying to coordinate their activities across space and time” is a hard fucking problem.
I feel like there is an unfair sentiment of competence elitism in the software engineering world.
I don't think you can stop less experienced engineers (or experienced but still bad engineers) from contributing to projects - especially at the scale of a lot of these large organisations.
After all, for people early in their careers, being bad is the first step to being good and it's impractical (or impossible) for organisations to exclusively hire "premium" engineers.
There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today.
Project architects should instead strive to design their systems such that they expect low quality contributions and limit the potential damage those contributions can have. Systems should be able to take a low quality contributions and if the need arises, have the capacity for those circuits to be optimised at a later date without rewriting the entire thing.
I personally find the argument that "bad engineers make microservices bad" to be silly. Bad engineers would poison any poorly architected project, be it a monolith, microservice or otherwise. Microservices are just an architectural optimisation with trade offs that some organisations find value in.
That's the problem with software - it's decisions all the way down. Outside of prototyping, there's very little "work" to be done that doesn't contain some kind of systems decision.
this can be limited though. I just went through refactoring a whole set of classes that implement the same interface, but it was not defined as an Interface. now any new class that implements this _must_ meet at least some expectations, enforced by the code.
So in one way, OOP is great for limiting side effects.
Sorry that you've worked for some horrible companies. What you described has not been my experience over the last 10+ years at some rather large and now public tech companies. Part of a Senior's job duties are to mentor Juniors and most job descriptions explicitly list that as an expectation of the Senior role.
Often make the decisions. I’m talking about mentoring. Which is what my first comment was specifically mentioning. Which was in response to the parent comment saying mentoring didn’t happen.
> they're called juniors and every other industry has seniors to help guide them and ensure they don't make major mistakes.
> Except in our industry. In our industry the juniors often are the ones making the decisions.
"Except in our industry". Said after "every other industry has seniors to help guide them and ensure they don't make major mistakes".
I speak perfect english, dumbass. You need to read your own words because you said seniors mentor jrs. Except in our industry. And then closed with a sentence unrelated to everything else you said, "in our industry the juniors often are the ones making the decisions", which has dick to do with mentoring, the thing everyone else had been talking about up until that last line.
Building construction has been going on for ~thousands of years now. Buildings still fall down. The IT industry is doing remarkably well for its first 70 years.
Inexperienced engineers aren't the problem. Juniors will submit spaghetti code messes, but those can be cleaned up without too much trouble. The real problem is incompetent people higher up that can make large scale architecture and design decisions. e.g. somewhere I used to work there was a VP that decided to hand roll an ORM instead of just using Django.
I'm all for raising the bar of engineering standards though realistically enforcing that would be a significant logistical challenge.
Consider that there are varying levels of competence required for the different problems in software - for instance someone writing code for medical equipment requires a different type and level of expertise than someone writing a website for a small business.
Consider how many YouTubers and blog posts are out there giving bad advice.
Consider how easy it is to get started but also how many niches there are with differing skill sets required by each niche.
Perhaps we could implement a "bar" exam for programmers - however for which niche would it apply? How many different exams would need to be drawn up? By whom and how would this be coordinated internationally?
Does this apply to esoteric segments like Excel or jobs that rely on basic scripting like bash/powershell/SQL/Python?
Would we need to restrict people from giving advice on platforms like YouTube through a licensing system? - much like how it's illegal to give financial advice online without a license in some countries.
It would be nice but I do think that it's extremely ambitious. I struggle to see how it could be implemented inside of a decade long time frame.
I've seen clients run automated architecture tests with varying degrees of success. These reduce damage done by juniors.
For example tests that ensure that controller actions don't create SQL queries directly but instead always use repositories/services/models (whatever you call data fetching layer).
Another example is a test that ensures that there's no "print" in data fetching layer, only allowing them in HTTP controller actions.
> There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today.
I only agree if the person who lacks passion can actually do the job and has experience. The trouble with programming computers is that you cannot get sloppy with the implementation details or design decisions. It is absolutely not a field accessible to people who guess too much and code by coincidence.
Often those details are also overlooked at the project planning level so it's unfair to everyone else who has to pick up their slack. It's already bad enough that the people in charge usually don't understand the project very well.
This sounds in line with Google creating go: restrict the language features so you can hire mass quantities of programmers and be reasonably sure they won’t go off the rails. It’s fine for what it’s for but doesn’t seem like that should be the goal of most programming projects?
Especially with AI copilots getting better, it feels like we’re headed for a point where you’re either capable of architecting complex systems, or there isn’t much software for you to write: other industries tend to have rote work for beginners while they gain skills, but in software rote work tends to get automated away. AI can help people learn faster, but given what AI has proven good at, I expect more of the gains will go to expert productivity. (or non-programmer domain experts)
I think AI copilots will allow more people to be productive in software and, by so doing, allow vastly more software to be created.
Related to that idea is that, with the right definition (unconventional but not tortured), I think that more software is created in Excel than in python today and a large swath of the people making spreadsheets today for their business will be using AI copilots to make better software 20 years from now.
Totally agree. AI empowers people with existing software expertise, and empowers people with domain knowledge. Both of which have historically been bottlenecked by things AI is now getting good at.
I'm sorry if it came across this way. It was definitely not intentional! My opinions perfectly match yours, in fact :)
I did try to point out that I don't really blame normal devs but the leadership instead. A fish rots from the head. My writing skills are just not that good (yet) :)
I also used "incompetence" very broadly which was probably a mistake from writing perspective. From bad management decisions all the way to brilliant engineers simply not being familiar with a particular technology/paradigm.
This article seems to be trying to get in way too much, but I appreciate the initial sentiment.
The sad truth is, a smart team can do well with any architecture. A weak team will fail with any architecture. And maybe it's not really too sad.
I've seen organisations that really kick ass using microservices, and I've seen some microservices horrorshows too. The difference is having teams that are talented enough to get the benefits of any given technique and mitigate the drawbacks well. Those teams will execute any architecture to its maximum benefit.
> There’s also another category of people. Good (sometimes brilliant, even) engineers who know exactly what they’re doing but who simply don’t care enough to do the right thing.
Sometimes not doing the right thing is the right thing to do.
I don't know how CS is taught these days. In the 1980s I learned a lot about data structures, algorithms, and programming languages, virtually none of which I ever directly used in my later career. I've never had a job that required leetcode knowledge. I've never had to write a sort or a search or a tree balancing algorithm from scratch. There are libraries for anything you might want to do (and if there aren't, that's often a big red flag that you're doing something wrong).
I learned almost nothing about engineering. It took me quite a while on the job to learn and appreciate the practices that result in long-lived, maintainable systems. Overly complex, fragile systems with inscrutable interdependencies using esoteric frameworks are often the product of smart people who don't understand engineering principles (yet we often call them "engineers").
In the late 90's and early 2000's I learned all that data structure stuff but that was mostly in the first 2 years. Beyond that many classes were about software engineering, project management, etc. I learned Agile (then in it's infancy) as well as doing a complete waterfall project (which turned out poorly -- as expected). But even at that time most other schools did not offer those kinds of courses in their CS education.
In contrast, I've worked on 2 UI frameworks and knowing all about tree traversal was super useful.
I've sat next to the engineer who had to write various sort algorithms for the embedded runtime I helped design.
I've witnessed a file system get implemented from scratch.
I have walked through the Windows' kernel source code and knowing my fundamentals sure as heck helped to keep me grounded.
> (and if there aren't, that's often a big red flag that you're doing something wrong).
Or that you've chosen a career building the layers that underpin everything else.
I've found that life is more enjoyable when I understand how things work at a base level, and remembering my fundamentals opened up doors to work on cool projects.
I think "most of what I learned is inapplicable to my job" is kind of inevitable in any CS program that tries to expose students to a breadth of topics before they graduate and get hired into specialized jobs. The trick is that the "most" will vary from person to person.
As a fellow 1980s CS person, I too got a lot of DSA coverage, but I ended up using a respectable amount of it when I was working at low-level systems programming jobs. I have never used what I learned in my computer graphics class. But I had classmates who went into animation and used that stuff every day.
Agreed about the lack of any education about the "engineering" side of the work, though. One challenge is that engineering is mostly a group activity but education is focused on individual learning. With some exceptions, you don't get a group grades in classes, and usually, collaborating with other students on your homework or your tests is considered "cheating" rather than "teamwork." Professors aren't in the habit of repeatedly changing the assignment out from under you while you're halfway finished, but dealing well with unpredictably shifting requirements is a huge part of the job.
> Professors aren't in the habit of repeatedly changing the assignment out from under you while you're halfway finished
That would be quite interesting in terms of "real world" education. The unfortunate thing is that most terms/semesters are only a few months long and so work has to be very explicitly defined and scoped to be achievable in that time with the expectation of the student spending maybe 10 hours a week on any one class, tops.
I'd love to see that. Give everyone an assignment on day one. Nice and easy and due in 10 days. Then in 9 days extend the project scope. Require collaboration and then set the due date +10 again. Just keep repeating until the final submission when you programmatically test and grade every assignment in front of the whole class with a "big bang" style "deployment"
Another unfortunate thing in this context is that coursework is almost always greenfield development of small projects.
Coming up to speed on a large existing code base of inconsistent quality and style is another enormously important job skill, as is writing code that can be maintained by the person who has to come up to speed on your code a year later, but you'll never get those skills from writing small precisely-specified programs from scratch.
But CS is not engineering, CS is a branch of mathematics. I studied Finance at university and I've seen people complaining how it doesn't teach you how to invest in stocks and do M&A. Later, talking to professionals about what they do in their jobs I realized that what I'm being tough is adjastent, but they are not preparing you for a job. It's not like medicine where you get placements and they literally train doctors. Same with Computer Science, it's not software engineering and while the two are obviously adjacent. Damn I'm 6 years into my software engineering career as a self-taught guy, and I've contributed, implemented, and released projects that work well in the real world for non-trivial companies, but I am only now learning about algorithms and CS theory as a side project.
I think bootcamps try to fill that field but most of the ones I've seen are quite trivial, getting you through the basics. If you're asked to implement 10 greenfield CRUD APIs and then go to a job and have to maintain some huge monolithic repo it's going to be hard.
I think an educational approach where the curriculum involves some sort of "For this task, you have to change this thing in this codebase and deploy it without crashing the thing", "refactor this code base", giving people some sort of project and then switching it up in the middle would be valuable because it's mostly what software engineers do day to day: write tests, fix bugs, implement features in existing projects.
Microservices are a solution to an organizational challenge: how do we set clear boundaries of ownership within a complex system? From a technical perspective there are pros and cons.
Unfortunately, I don't see a wealth of other ready-made practices for companies to copy when they grow and need to solve this problem. I once worked on an enormous Rails monolith that was very well organized and had layered on several additional patterns to improve modularity and maintainability. Still, a SEV in a minor product area could (and did) bring down the whole system, and they were in the process of dismantling it.
Actually, loosely-coupled microservices improve testability, too. And improve it by far if we're comparing with monoliths (where tight coupling is considered a "feature").
One of the troubling practices is tightly-coupled containerized services, though, which only gives us all of the problems of microservices at the same time as we have all of the problems of monoliths.
A microservice architecture is a good way to solve the problem with the monolith. The problem is the word mikro. It should have a better name. If it was called "boundary architecture" or similar it would make people stop creating to small pieces. One team should not manage 15 services.
This - I worked with a guy that had been to a conference where someone from Atlassian said that S3 was made up of over 500 microservices, so this guy made it has mission to create as many microservices as possible in a 100 person company.
I agree, the precise granularity of "micro" isn't well-defined and I've seen teams (usually ones without prior practical experience) try to implement an "every database table is a new service" approach that ends up being ridiculous. I suppose the term Service Oriented Architecture avoids this problem, but it sounds a little too "Oracle enterprise" for my taste.
Microservices are Resume Driven Development, the leading paradigm of our industry and others. People will always optimize for the incentive structures of their environments.
The most important person in every company is the CEO. He sets down the culture of the company and creates these incentives either directly or indirectly. The only solution to RDD is for the CEO to be tech oriented, avoid hiring people who jump companies every couple years, build a great work environment, and compensate people well.
> avoid hiring people who jump companies every couple year
You don't get many of those people any more, because just about every other employer has burned that bridge to the ground. People, especially the young ones who entered their careers around the 2008ff megacrisis, have zero trust left in anyone.
When companies don't care and ditch us at the first sign of problems (easy, because we were the freshest hires), why should we show any sign of loyalty in return? If you want loyalty, pay us.
As I said, RDD is the dominant paradigm because it is rewarded. The career trajectory of someone who hops companies versus someone who doesn't is wildly different.
I also pointed out that the problem isn't with the developers but the leadership, starting at the top. The programmers are just acting rationally in the environment they are given. The value of a programmer is exponential with time in the code, and yet, they aren't compensated for it. What they are compensated for instead is decorating their resume for their next job.
Competent engineers never understand why others are not as competent as them. It'd be cute if they didn't then write thoughtleadership about how it's really simple to get rid of the cloud - you too can run your own datacenter, and custom kubernetes orchestration competitor. Just hire competent people!
Looking at ya, DHH.
And of course, it's the same thing here:
> The real problem, I think, is the lack of engineering competence and the lack of “giving a shit” in companies
OOOOH they should just hire competent people? I guess they never thought of that...
The author is not wrong, yet there's not enough sugar-coating to make this post appealing to wider masses. I believe that more than just a handful of us share some of those opinions and experiences, though.
These days everyone and their dog can become a "software engineer", unlike in other professions where the entry bar is significantly higher. Hence, you will find cabals of similarly average engineers agreeing with one another's opinions simply because it's an echo chamber.
This article misses that there is a business case for bad decisions. Sometimes there is no other choice than making a design shortcut, doing things that don't scale, overcomplicating or overabstracting. There is no sense criticising these decisions, typically made for good reasons for which the current view of the code does not provide an explanation. Sometimes you don't win the contract if your service doesn't work in three months (game over), sometimes there literally is no funding for more engineers, or a system hemmoraging existential amounts of money needs to be hotfixed. Moreover building a system can be like discovering a new scientific theory, only once it has been developed in an overcomplicated or overabstracted way, does the simple case actually become obvious.
If there is an "epidemic" of anything it's hindsight criticism of engineers who made the best decisions that they could. "Incompetence" is doing a lot of leg work in this article, this is not a real specific criticism by itself. To me this a symptom of over antrhopomorphising the failures of a company and glomming them onto a theoretical goblin for which you can blame the ills on.
I believe this behavior emerges from engineers that have not participated at a decision making level in the entire software development process at many different sizes of company in many different contexts. This means a startup from zero, a large company where the marginal cost of issues is so extreme that all code is mobbed, a mid size company being bought out, being in charge of a service from ideation, to development, to maintenance and deprecatio.
This is my main gripe with some newcomers of projects I have worked on.
They tend to spit out destructive criticism towards legacy code with such an ease and without any context on why things are the way they are.
My usual response, albeit in a more polite manner, is something along the lines of:
"Yes I know the code in this part of the system is not as nice as other parts. And if you bothered to ask why, I'd tell you it's because this code is 6 years old and we learned better ways to do the same thing since. It's called technical debt and we are always working to reduce it. There's no need to demoralize the engineers that worked on that part of the system."
Just from the title, I can deduce the article is based on a logical error. There will ALWAYS be incompetent people involved in any solution. So if solution X fails because of incompetent people, but solution Y succeeds, then solution Y must be better.
The same goes for the disclaimer at the end, "it's actually about incompetence across organisations", you will always have that.
75 comments
[ 3.2 ms ] story [ 159 ms ] threadBut the attitude that "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers" is a naive attitude.
If you're going to make claims that micro-services are failing at 9/10 companies you really should have a source.
There are no silver bullets that can solve this. Only well-designed systems accommodate for the flexibility of human error and hubris can do that.
> I understand it’s a harsh title and at times a harsh essay. Such is life. All opinions are my own.
Some takeaways you might have missed:
* Use the right tool for the job - one-tool shops are bound to fail
* (Similar to above) There is a tendency to find _a_ solution rather than the _optimal_ solution
* The engineering halo effect is real and prominent
Then the author goes on to provide some possible solutions:
* Using the SOLID framework for building
* Use services
* KISS
* Developer experience is very important
* Protect your time and your work
* Governance is required to enforce certain principals.
I don't agree with all of these, but they are certainly worth considering.
I did find that lots of people who disliked it, mainly just got put off by the overall tone and the provocative statements from the get go. I basically blame my writing skills (and maybe personality haha). This essay lacks structure and it's more of a stream of thought (sometimes jumping all over the place and going off topic).
I'll just have to live and learn :)
It's even worse than naïve, it's a literal fallacy, a "No true Scotsman" with technology.
System resilience is important at scale, and resilience includes being resilient to the failures in the human component of development; if a system depends that every one developing it to be a master of the underlying foundation then you'll require lots of very specialised, competent people who mastered the technique. That is very costly, if microservices depend on high mastery then we should budget the cost of the talented people required to run it.
My experiences with how to successfully deploy microservices include much the opposite: giving tooling to incompetent people to avoid the worst footguns, training them in best practices over time while designing an architecture that is somewhat resilient to their inevitable failures, one that is easy to be fixed when they've learned how to best use it.
And even in those 9/10 companies, the failure doesn't even prove that the engineers are the ones unable to create meaningful service boundaries, within a monolith or distributed to multiple services. All of those engineers have bosses and, I don't know what others are seeing, but I feel like I've seen Software Development Manager increasingly become Manager of Software Developers.
I suggest that those same management structures which failed to enable their engineers to create meaningful service boundaries in their monolith, which led to the desire for a cure-all solution, also failed to manage (or protect) their developers such that those developers _could_ turn the existing system architecture into one based on microservices.
Technical leadership has just become increasingly abysmal. Developers are tasked to fulfill user stories but those are often written in a way that completely ignores the technical work required to fulfill such a story. That creates a painful disconnect between expectations and reality, even in 90% CRUD, monolith web apps. Even in a monolith with proper separation of concerns, its easy to imagine one service being the "user" of another service for the purpose of more granular and clear tasks but, "that's not how user stories work." :(
Yep, which is why it's the problem. You will always have incompetent people.
If you get to work on one of those codebases ... good for you. The rest of us are just trying to gatekeep piles of shit from getting in while being pushed by management to open the flood gates.
Write code and design systems so 3am you can fix them!
I don't think you can stop less experienced engineers (or experienced but still bad engineers) from contributing to projects - especially at the scale of a lot of these large organisations.
After all, for people early in their careers, being bad is the first step to being good and it's impractical (or impossible) for organisations to exclusively hire "premium" engineers.
There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today.
Project architects should instead strive to design their systems such that they expect low quality contributions and limit the potential damage those contributions can have. Systems should be able to take a low quality contributions and if the need arises, have the capacity for those circuits to be optimised at a later date without rewriting the entire thing.
I personally find the argument that "bad engineers make microservices bad" to be silly. Bad engineers would poison any poorly architected project, be it a monolith, microservice or otherwise. Microservices are just an architectural optimisation with trade offs that some organisations find value in.
Except in our industry. In our industry the juniors often are the ones making the decisions.
So in one way, OOP is great for limiting side effects.
> Except in our industry
> Except in our industry. In our industry the juniors OFTEN are
try again.
I suppose for some implication is difficult to deal with so let me be explicit.
there often are no seniors. A junior mentoring has another phrase. The blind leading the blind.
You said every other industry the seniors guide the jrs, except ours.
I disagreed, and said it's been my experience that seniors are always mentoring jrs.
That's all I was ever trying to reply
I didn't say that the first time and I didn't say that the second time when I pointed out you were cherry picking.
At what point do you admit that maybe I know my point better than you and your caricature aint it?
If you're not a native speaker then I understand, otherwise lrn2read.
> Except in our industry. In our industry the juniors often are the ones making the decisions.
"Except in our industry". Said after "every other industry has seniors to help guide them and ensure they don't make major mistakes".
I speak perfect english, dumbass. You need to read your own words because you said seniors mentor jrs. Except in our industry. And then closed with a sentence unrelated to everything else you said, "in our industry the juniors often are the ones making the decisions", which has dick to do with mentoring, the thing everyone else had been talking about up until that last line.
In the US buildings have to adhere to legal specifications specifically to ensure that doesn't happen.
And I feel like there are people in software that complain about things like "competence elitism" when other industries encourage doing things right.
Take actual engineers, for example:
https://www.nspe.org/resources/ethics/code-ethics/engineers-...
Consider that there are varying levels of competence required for the different problems in software - for instance someone writing code for medical equipment requires a different type and level of expertise than someone writing a website for a small business.
Consider how many YouTubers and blog posts are out there giving bad advice.
Consider how easy it is to get started but also how many niches there are with differing skill sets required by each niche.
Perhaps we could implement a "bar" exam for programmers - however for which niche would it apply? How many different exams would need to be drawn up? By whom and how would this be coordinated internationally?
Does this apply to esoteric segments like Excel or jobs that rely on basic scripting like bash/powershell/SQL/Python?
Would we need to restrict people from giving advice on platforms like YouTube through a licensing system? - much like how it's illegal to give financial advice online without a license in some countries.
It would be nice but I do think that it's extremely ambitious. I struggle to see how it could be implemented inside of a decade long time frame.
For example tests that ensure that controller actions don't create SQL queries directly but instead always use repositories/services/models (whatever you call data fetching layer).
Another example is a test that ensures that there's no "print" in data fetching layer, only allowing them in HTTP controller actions.
That's the gist of it.
This phrase says it all.
But why doesn't the review process help to improve the quality?
And to a lesser extent some use Pair Programming.
Automated architecture tests helps to keep things tidy during those rushed moments.
Is there some good links to know more about it?
For C#:
1) https://github.com/TNG/ArchUnitNET
For PHP:
1) Pest testing framework demonstration: https://youtu.be/ZidLP7TqXnc?t=133
2) https://github.com/spaze/phpstan-disallowed-calls
3) https://github.com/ekino/phpstan-banned-code
4) https://packagist.org/packages/ta-tikoma/phpunit-architectur...
5) https://qossmic.github.io/deptrac/
Hope that helps.
I only agree if the person who lacks passion can actually do the job and has experience. The trouble with programming computers is that you cannot get sloppy with the implementation details or design decisions. It is absolutely not a field accessible to people who guess too much and code by coincidence.
Often those details are also overlooked at the project planning level so it's unfair to everyone else who has to pick up their slack. It's already bad enough that the people in charge usually don't understand the project very well.
Especially with AI copilots getting better, it feels like we’re headed for a point where you’re either capable of architecting complex systems, or there isn’t much software for you to write: other industries tend to have rote work for beginners while they gain skills, but in software rote work tends to get automated away. AI can help people learn faster, but given what AI has proven good at, I expect more of the gains will go to expert productivity. (or non-programmer domain experts)
Related to that idea is that, with the right definition (unconventional but not tortured), I think that more software is created in Excel than in python today and a large swath of the people making spreadsheets today for their business will be using AI copilots to make better software 20 years from now.
I did try to point out that I don't really blame normal devs but the leadership instead. A fish rots from the head. My writing skills are just not that good (yet) :)
I also used "incompetence" very broadly which was probably a mistake from writing perspective. From bad management decisions all the way to brilliant engineers simply not being familiar with a particular technology/paradigm.
The sad truth is, a smart team can do well with any architecture. A weak team will fail with any architecture. And maybe it's not really too sad.
I've seen organisations that really kick ass using microservices, and I've seen some microservices horrorshows too. The difference is having teams that are talented enough to get the benefits of any given technique and mitigate the drawbacks well. Those teams will execute any architecture to its maximum benefit.
Sometimes not doing the right thing is the right thing to do.
I learned almost nothing about engineering. It took me quite a while on the job to learn and appreciate the practices that result in long-lived, maintainable systems. Overly complex, fragile systems with inscrutable interdependencies using esoteric frameworks are often the product of smart people who don't understand engineering principles (yet we often call them "engineers").
I've sat next to the engineer who had to write various sort algorithms for the embedded runtime I helped design.
I've witnessed a file system get implemented from scratch.
I have walked through the Windows' kernel source code and knowing my fundamentals sure as heck helped to keep me grounded.
> (and if there aren't, that's often a big red flag that you're doing something wrong).
Or that you've chosen a career building the layers that underpin everything else.
I've found that life is more enjoyable when I understand how things work at a base level, and remembering my fundamentals opened up doors to work on cool projects.
As a fellow 1980s CS person, I too got a lot of DSA coverage, but I ended up using a respectable amount of it when I was working at low-level systems programming jobs. I have never used what I learned in my computer graphics class. But I had classmates who went into animation and used that stuff every day.
Agreed about the lack of any education about the "engineering" side of the work, though. One challenge is that engineering is mostly a group activity but education is focused on individual learning. With some exceptions, you don't get a group grades in classes, and usually, collaborating with other students on your homework or your tests is considered "cheating" rather than "teamwork." Professors aren't in the habit of repeatedly changing the assignment out from under you while you're halfway finished, but dealing well with unpredictably shifting requirements is a huge part of the job.
That would be quite interesting in terms of "real world" education. The unfortunate thing is that most terms/semesters are only a few months long and so work has to be very explicitly defined and scoped to be achievable in that time with the expectation of the student spending maybe 10 hours a week on any one class, tops.
I think it would be too real for the kids.
Coming up to speed on a large existing code base of inconsistent quality and style is another enormously important job skill, as is writing code that can be maintained by the person who has to come up to speed on your code a year later, but you'll never get those skills from writing small precisely-specified programs from scratch.
I think bootcamps try to fill that field but most of the ones I've seen are quite trivial, getting you through the basics. If you're asked to implement 10 greenfield CRUD APIs and then go to a job and have to maintain some huge monolithic repo it's going to be hard.
I think an educational approach where the curriculum involves some sort of "For this task, you have to change this thing in this codebase and deploy it without crashing the thing", "refactor this code base", giving people some sort of project and then switching it up in the middle would be valuable because it's mostly what software engineers do day to day: write tests, fix bugs, implement features in existing projects.
Microservices adoption has largely become a cargo cult thing. It is a part of being cool like FAANG.
Instead of being cool, focus on solving your problems.
This needs repeating to every dev every week. Myself included
Unfortunately, I don't see a wealth of other ready-made practices for companies to copy when they grow and need to solve this problem. I once worked on an enormous Rails monolith that was very well organized and had layered on several additional patterns to improve modularity and maintainability. Still, a SEV in a minor product area could (and did) bring down the whole system, and they were in the process of dismantling it.
One of the troubling practices is tightly-coupled containerized services, though, which only gives us all of the problems of microservices at the same time as we have all of the problems of monoliths.
> Not being smart is totally fine (I certainly am not one). We just need to avoid being stupid.
> Let’s face it, engineers, most of us aren’t smart
> most people don’t give enough shit to improve
Barely even makes sense, and is just a bunch of random opinions
The most important person in every company is the CEO. He sets down the culture of the company and creates these incentives either directly or indirectly. The only solution to RDD is for the CEO to be tech oriented, avoid hiring people who jump companies every couple years, build a great work environment, and compensate people well.
You don't get many of those people any more, because just about every other employer has burned that bridge to the ground. People, especially the young ones who entered their careers around the 2008ff megacrisis, have zero trust left in anyone.
When companies don't care and ditch us at the first sign of problems (easy, because we were the freshest hires), why should we show any sign of loyalty in return? If you want loyalty, pay us.
I also pointed out that the problem isn't with the developers but the leadership, starting at the top. The programmers are just acting rationally in the environment they are given. The value of a programmer is exponential with time in the code, and yet, they aren't compensated for it. What they are compensated for instead is decorating their resume for their next job.
Looking at ya, DHH.
And of course, it's the same thing here:
> The real problem, I think, is the lack of engineering competence and the lack of “giving a shit” in companies
OOOOH they should just hire competent people? I guess they never thought of that...
These days everyone and their dog can become a "software engineer", unlike in other professions where the entry bar is significantly higher. Hence, you will find cabals of similarly average engineers agreeing with one another's opinions simply because it's an echo chamber.
If there is an "epidemic" of anything it's hindsight criticism of engineers who made the best decisions that they could. "Incompetence" is doing a lot of leg work in this article, this is not a real specific criticism by itself. To me this a symptom of over antrhopomorphising the failures of a company and glomming them onto a theoretical goblin for which you can blame the ills on.
I believe this behavior emerges from engineers that have not participated at a decision making level in the entire software development process at many different sizes of company in many different contexts. This means a startup from zero, a large company where the marginal cost of issues is so extreme that all code is mobbed, a mid size company being bought out, being in charge of a service from ideation, to development, to maintenance and deprecatio.
They tend to spit out destructive criticism towards legacy code with such an ease and without any context on why things are the way they are.
My usual response, albeit in a more polite manner, is something along the lines of:
"Yes I know the code in this part of the system is not as nice as other parts. And if you bothered to ask why, I'd tell you it's because this code is 6 years old and we learned better ways to do the same thing since. It's called technical debt and we are always working to reduce it. There's no need to demoralize the engineers that worked on that part of the system."
Thanks for sharing! I usually just go with reddit and my linkedin (which barely has any network anyway haha).