We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cats, and all night coding. We all agreed we probably could have done it in half the time with just the 5 leads.
This is a problem across many job functions. It's always faster for "just the pros" to bang out a project or deliverable but it's usually in the company's interest to also be training more pros.
Every more junior person on a project is going to be less efficient than a senior person but they need to level up and go through the apprenticeship phases to become a senior person.
Very small companies or teams can tactically choose to pay more and only hire top talent but most places will need to develop internal talent due to budget, recruiting, or bus factor (business resiliency) constraints.
The problem is most of these pros were high-priced consultants who left as soon as the project finished. On top of that some of the stuff they built was a huge dark gray box to us for years.
the problem is the quality of training, i can't see lots of high quality training (it exist) but isn't available like in other areas, 1 most training is buzzword centric learn this new tool, we have "methodologies" but most of them are trash, and optimize for managers convenience and feeling of control, not output, they are books out there who teach you basic of system design, and fundamentals (even this is full of bullshit like, java architects), but they are scarce and is harder for manager to justify spending in this instead of this new tool who will revolutionize the world in the next 5 year and give the manager and increase in responsibilities.
Then the non-pros never have the opportunity to learn from the pros and the pros never get a break which leads to employee morale and retention issues + tacit knowledge loss.
Pros get burnt out being constantly called on to crank out new features under pressure and never get to leverage their deep understanding in the maintenance phase.
Non-pros have no upward mobility (career progression) and get burnt out struggling to understand and maintain unfamiliar code without any guidance.
I've experienced a different situation where I was one of two pros – pillar may be more appropriate – in a team of around 15 devs – and wasn't recognized as such. I was working 70h/week on average (I never was paid for those overtime hours and my actual hourly wage was under the minimal wage), taking in charge every and any issue that may pop up, I was a reference when it came to knowing how our system worked and people would come ask me questions about the inner working of some part even when they had designed it ! I left disgruntled, and the other piller followed course because I wasn't here anymore to buffer the conflict he had with the CTO. In spite of the new hire and organizational restructuration to fill the gap, what should have taken 2 weeks to implement (a few hours to a few day in the redesign I had reimplemented at home in the weekend following my departure), took them 6 months. They had to distribute overtime hours to every dev, and in the end I received a call from the guy in charge of HR who told me the company was considering rehiring me at the condition I should behave ! Dude was fired eventually and replaced by a manager from the holding company.
As for pros needing training by other pros, I think it's more a question of culture. Once I was tasked with adapting a microservice to also run as a library, the challenge being we used JSON fields and now also had to store them in a mysql database that did not support them natively. I wrote an adapter that could have been released as a separate library because it was that generic, it took me 1 day of work, a 15 files long PR. But because it used a postwalk traversal on tiny json data triggered lazily upon accessing the specific field, cached in the ORM object for repeated access, it smelt funny to the CTO who proceeded to ditch my work away, spend the 3 following days adapting 350 files to try to get a highly specific solution then gave up, and decided in the end we'll have two separate versions of that system, in concurrent use, one as a lib and one as a microservice, hence multiplying by two the time it took to do changes to that highly repetitive codebase because "it was simpler that way".
You don't need to train pros, they have been training on their own since they are twelve.
Reasonable argument, I like it, however would add a bit of salt:
I've seen several times so far that people maintaining things are actually doing a much better job, while those who were granted honor of doing a new thing because hey they are "pros". And once they did the prototype, they are _considered_ even more "pros", because hey, they wrote it. The people who rethought and rewrote the thing later were real makers, but didn't get the appreciation of "pros".
The worst thing is that "pros" status keeps working for itself, even while delivering worse job. I wouldn't have a problem if the system could fix itself over time.
I've been on both sides of this fence. As a maintainer, you have all the time in the world to understand the system, as it is, and improve it. You have the benefits of hindsight.
As a producer of the mvp, a lot of times there is 'exploratory code' where you're not actually sure how it will work yet; or scale. So you bang out a few approaches and pick the best one for the constraints you have. And basically never touch it again.
In one case, I was working on the mvp and the team who would be maintaining it where the one's doing code review. The code turned out way better than either of us would have come up alone. It ended up being one of the coolest projects in the company and some internal secret-sauce for making money. For example, I remember one code review where they asked to add a configurable callback in. I was like 'why?' and they answered, "we're already being asked if it can do X, if you add a callback here, here and here, we can already start building that feature so you can focus on the core."
Yes, but when a "pro" takes too long to deliver something, then that thing is considered hard, because even the "pro" cannot make it quickly.
Re. scaling -- probably, agree, just I never seen myself (working in distributed systems). On my personal experience it was always more-less clear, depending on what software/database/data types we intended to use. So before implementing an MVP, I could roughly answer what price/scalability it would have. But I can see it might have, especially in fields of statistics/ML/new algorithms. E.g. "try using SIMD for this new sorting algorithm" -- only tests could show if it's any better.
But in that areas, usually managers shouldn't judge by outcome anyway, but rather by how fast they make and test hypotheses.
Wow, that blog post post was a breath of fresh air. Can you believe it was written almost six years ago? She is really seeing into the future. Unbelievable.
Maintenance benefits from "pro" skills as much as creation does; you can break something just as easily with maintenance work as with new features if you're not good at it.
To me that's a wrong way to look at software maintenance.
What do you think leads to a better result?
- I create software that I _want_ to maintain and _will_ maintain.
- I create software that I think someone else wants to maintain, I leave the project after.
At least in open source, some of the most praised and successful software was built _and_ maintained by the same people at least for a substantial amount of time.
Thinking about it, this pattern of "I, the rock star will build it, you the code monkey will maintain it." Is a red flag.
I struggle with that all the time. We have a lot of offshore people and I am pretty sure that 3 experienced people could take on a project that requires 50 offshore people and get it done in less time at higher quality.
Offshore generally means you're trying to slash costs. Say, hiring $10/day devs from India. Now, there are great devs in India, but they don't work for $10/day.
It's the same term that was used for transitioning textile and other factory work to third world sweatshops.
Hiring internationally is just that. You might get someone for a bit cheaper (somewhere in the neighborhood of 20ish percent), but that's usually in exchange for the extra hassle of managing a remote team and dealing with timezone issues. You don't usually crank through these people every quarter, they're hired for the longterm (or, as longterm as anyone in a software job is hired for).
I worked on a team with two other engineers. I was in the EU, one was in Australia, and one on the west coast of the US.
We had very, very little overlap to have meetings (unless one of us wanted to wake up early or have a late night meeting, which happened a few times). We did everything async, even meetings and decisions.
The best part would be learning how to open a WIP PR, with enough detail that someone else could understand what you were going to do. You'd wake up in the morning to find a team member had contributed to your PR, either by fixing nits (we didn't have time to go back-and-forth on shenanigans or it would take weeks just to merge a single PR), or by actually implementing some idea they had. So, if you didn't like it, you'd just remove that commit from your PR.
I had the "timezone thing" with a colleague in the same city because he had some weird sleep disorder. Basically, he was a vampire. Asleep during the day, working all night.
It was awesome. I'd turn up to the customer site to collect their issues and requests, do some investigation, formulate the precise requirements, and send it off to him.
The next morning, magically, things would be done.
When you offshore cost is the main factor and the companies optimise for it. As an example you may have an offshoring contract with Infosys where you pay around $20/hour/head and they provide mostly freshgrads (some times referred to as "commodity developers") with dubious qualifications. But you can say you have 100 engineers on the project. When hiring internationally you usually hire and interview a specific person and pay them well through Deel (or equivalent). All of the former engagements have been a disaster, the latter have mostly worked out.
Both have their benefits. In my experience offshore teams are basically an army that you need to train and provide a lot of direction. It can be very frustrating but if you have code generators, Sonarqube, linters and they are only working on CRUD applications it sometimes works out. Whereas international hires are usually very competent because you personally selected them.
To me, "offshore" means acquiring developers from international shops that bid for US contracts, whereas hiring internationally just means hiring outside the country on an individual basis.
Speaking very broadly here, my impression is that those offshore development shops bidding for US contracts often don't have the greatest working conditions. Those talented enough to know their worth and find better options will do so if the opportunity presents itself, which could mean either applying for international positions on their own or immigrating to where the jobs are. Thus there's an outflow of talent away from those offshore companies.
Offshoring is contractors. They (usually) will code exactly what you tell them, and no more. They are not "product oriented" and won't push back on things if they make no sense -- they'll just shake their heads and get it down in the fastest way possible. They are not here "for the mission" and often don't care about maintainability. It's not their fault, they know they could be let go at any time, and any personal relationships they might build in the company won't save them come budget time. So you know, they're kind of checked out. On top of that you have timezone issues and potential language barriers.
Hiring internationally, you might have TZ and language issues but none of the other stuff. If you do your hiring right that is, you'll get somebody who actually wants to be part of the team and is product oriented.
I think the poster is hinting at skill level, where "offshore" is low skill in a cheap location, and "hiring internationally" means high skill in any location (or provide visa to move to high cost location).
One thing that I have found with "offshore" hiring: The very best have _mostly_ migrated to high cost locations because they get a huge salary increase (far more than cost of living increase). There are _some_ exceptions where the candidate is very high skill, but needs to live in a developing country. Usually family or cultural reasons. However, they are very hard to find and harder to keep.
The difference is only implied in their comment. They are using "offshoring" to referring to relying on a completely outside team to deliver a product.
In comparison to hiring individuals internationally to work with an internal team.
In the first case the entire project is "offshore." In the second case only individual team members are not in the primary country.
I struggled with this a lot too. I came to the conclusion that an offshore developer who as good as a good onshore developer costs about the same, just due to supply and demand, so it's a wash. If a company can't find or retain talent, hiring a not great developer offshore is cheaper than hiring a not great developer onshore. It's an "I give up" strategy; you can build the same mediocre, buggy crap cheaper offshore. Plus, off shore sales people are very good and promise the world. Many traditional executives are gullible when it comes to technology, but they're pretty good at turd polishing, so that's also part of it too. I also think OpEx vs CapEx accounting has a lot to do with it as well.
> We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cats, and all night coding. We all agreed we probably could have done it in half the time with just the 5 leads.
20 developers is a lot, but could in theory be worthwhile. I'd really try to get all 20 be very-effective ones and structure the responsibilities and communication so that they don't get bogged down. If you do it a naive way, and aren't lucky, it'd be easy for 20 1x..10x developers to become 0.01x developers.
Or, if you get people who just want to call themselves a "dev" and grind concrete task assignments in a straightforward way, then I think you either need to be doing something bog-standard and naturally amendable to just going through the motions (e.g., scalable Web CRUD, or yet another forum/chat app), or you need a brilliant approach to structuring the work.
> 20 developers is a lot, but could in theory be worthwhile. I'd really try to get all 20 be very-effective ones and structure the responsibilities and communication so that they don't get bogged down. If you do it a naive way, and aren't lucky, it'd be easy for 20 1x..10x developers to become 0.01x developers.
I don't think it makes sense to talk in terms of absolute numbers. It depends on the size of the company and what they're trying to build. It's more like "n good developers are faster than 10*n shit developers". If you have enough essential complexity in what you're selling to your users you could realistically have 50s or 100s of developers where every single one of them is like "startup grade" and has their own projects with their own responsibilites, their own autonomy and low communication overhead.
The problem isn't companies that have 200 devs. It's companies that have 2000 devs that could run with 200 (or companies that have 200 devs that could run with 20, or companies with 20 that get outcompeted by 2 people in a garage). I've seen all of them at some point in consulting.
The hardest thing, as noted by others, is managing the auxillary complexity -- which is often introduced by excess, sometimes underskilled, developers.
The 'good' (whatever that means) devs will waste more of their time hacking around the above... so more devs are added to compensate... repeat a few times: Fred's prophecy becomes manifest.
