The Lone Developer Problem • Hacker News Board

Re: The Lone Developer Problem

#101

Post by gonzo41 » Tue, Feb 28, 2023, 9:29 AM UTC

The lone developer problem I see is that it's cheap to start things, get them working and then it's really hard and boring to maintain things. So it's just easier to make more stuff.

Like consumerism, development creates stuff that just won't rot away, A lot like polystyrene cups. Code lives too long and of course it gets hard to understand as the domain experts retire or move on.

I work on a legacy software stack that started just before php was invented, Parts of it are php2. There's some aspx junk in there and a bit of crazy c-sharp inside sql server procs. It's wild.

However, I'm learning the business logic as we repair it and port it to a more standard stack. The young people who work with it are also learning it and that helps everyone understand what was going on.

If this project has lasted 5 years the cowboy shit that was done in the 90's wouldn't matter. But here we are, fixing things and writing tests and putting it in CI/CD so we can get a more orthodox boring solution because I know it's easily got another 20 years on the books.

Re: The Lone Developer Problem

#102

Post by jhoelzel » Tue, Feb 28, 2023, 9:29 AM UTC

Guys, this is obviously a marketing piece.

The number of developers usually is a velocity problem.... But this guy would like to work with you on the one person code.

Re: The Lone Developer Problem

#103

Post by vbezhenar » Tue, Feb 28, 2023, 9:32 AM UTC

samsquire wrote: post #4

This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself. With thousands of files and thousands of lines of code it's difficult for me to work out how the code fits together. If you document your mental model of how the code works, I can probably map the code to your mental model and understand the code. I want/like people to create "entrypoint" packages/folde…

That's why I hate Spring and similar technologies. They autostart things everywhere. Even from library jars. So terrible.

If I would write Java program for myself, I wouldn't use Spring. I would use dependency injection, but I would construct all objects manually, calling their constructors and setters. I did that, it works, it maintainable. Some repetitive code, but it's so much easier to reason about compared to reflection monsters or autogeneration nightmares.

Re: The Lone Developer Problem

#104

Post by danjac » Tue, Feb 28, 2023, 9:34 AM UTC

If you're a sole developer you can do quite a few things short of bringing in other developers: good test coverage, linters and formatters (in git pre-commit hooks or CI) etc.

For example, I try to aim for 100% test coverage in solo projects - that might be overkill in a project of multiple team members all reviewers and testing each others' code, but keeps me from making stupid mistakes when there's no-one else looking over my shoulder.

Another thing is how much you dog-food your project - if you are building something you use yourself every day, you are going to surface bugs and feature requirements better.

Re: The Lone Developer Problem

#105

Post by cs02rm0 » Tue, Feb 28, 2023, 9:42 AM UTC

flohofwoe wrote: post #91

In my experience it's more often the other way around. Most projects I've seen with actually readable code and a consistent overall structure have been written (mostly) by a single coder, of course usually with contributions from others, but not real 'team work'. Of course there are also messy projects by single authors, and readable code bases by teams. But in the latter case: the more the responsibilities are sprea…

Completely agree.

I think the flaw is that someone believes they turn up to a project and in reviewing code to fit it to a mental model they understand they believe they're improving the readability for others who think like them.

In reality it becomes design by committee, worst of all worlds.

Slightly tangential, but I'm about to leave a project where it gets the review process badly wrong - anyone can and will comment on a review, but only a select few can merge. They have a massive bottleneck of reviews with many held up by conflicting style preferences, or comments on neighbouring code not modified, none of which is able to be resolved by agreement as no one willing to take authority over any one view. Even the simplest one line change can't get merged within a month which essentially means development has stalled other than for the few who have merge rights.

Give me a lone developer's codebase to wrestle with any day.

Re: The Lone Developer Problem

#106

Post by danjac » Tue, Feb 28, 2023, 9:45 AM UTC

globalreset wrote: post #22

Does not fit my experience. Best software I've seen was always single good developer. Plenty of great single-person open source software out there to prove it. The problem is - good devs are actually very rare. A single not so good developer doesn't get any feedback, yet they have all the clarity and context in what their code is doing, so they can take their terrible code quite far.

As a sole dev you are also pushed towards simplicity, because your time and scope is so limited.

So a larger team might build some intricate DDD-microservices architecture with a services bus and a complex SPA frontend because, why not? That's what everyone else does.

As a single developer managing multiple microservices or separate backend/frontend codebases is a lot of overhead (unless it's a learning project). You have to do the simplest thing that will work. So if you can get away with server-side rendering, do that. A monolith makes more sense when you don't have multiple pizza teams, and so on.

Re: The Lone Developer Problem

#107

Post by wruza » Tue, Feb 28, 2023, 9:45 AM UTC

bartread wrote: post #50

ilaksh wrote: post #43

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else. 100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. E…

This reads like a very theoretical perspective. In 23 years of software development I've picked up or handed over, both solely or as part of teams (mainly the latter), dozens of projects across seven companies. Some of these were projects bought as part of acquisitions. In only three cases was a rewrite performed, and in only two of those cases was it justifiable (both of which involved creating a new version of the…

It’s a function of experience. The more experienced you are, the less you want to rewrite. Sometimes you start in an experienced team and this comes for free.

Re: The Lone Developer Problem

#108

Post by whstl » Tue, Feb 28, 2023, 9:46 AM UTC

flohofwoe wrote: post #91

In my experience it's more often the other way around. Most projects I've seen with actually readable code and a consistent overall structure have been written (mostly) by a single coder, of course usually with contributions from others, but not real 'team work'. Of course there are also messy projects by single authors, and readable code bases by teams. But in the latter case: the more the responsibilities are sprea…

Yeah, exactly the same in my experience too.

In fact, the biggest software atrocities I ever saw were team-based, with people having different opinions and wanting to modify the architecture every six months. And getting away with it because there was no vision.

This is where a good team lead or technical lead, or even Fred Brooks' "Surgical team", or your example of "single developer and contributors": have one person with the vision making the difficult architectural decisions and you'll get some conceptual integrity.

What I see a lot is people with little experience who learned things one way and become unable to understand or respect working code and want to change everything purely for personal preference. Maybe this is where the bias against lone developer code comes from.

Re: The Lone Developer Problem

#109

Post by whstl » Tue, Feb 28, 2023, 9:52 AM UTC

skissane wrote: post #69

bartread wrote: post #50

Earlier quoted context omitted.

This reads like a very theoretical perspective. In 23 years of software development I've picked up or handed over, both solely or as part of teams (mainly the latter), dozens of projects across seven companies. Some of these were projects bought as part of acquisitions. In only three cases was a rewrite performed, and in only two of those cases was it justifiable (both of which involved creating a new version of the…

Something I’ve repeatedly observed in my career: the rewrite is started, but it never gets finished, and then the rewrite and the original coexist long-term “Never gets finished” takes different forms. Two I’ve observed: Form (1): half the product gets rewritten in the new language/framework/stack, but the other half stays in the original - for whatever reason, rewriting the other half never happens. I once worked on…

Another common issue is the product team just going crazy with new features on the rewrite. Which makes sense from a business perspective but turns it into a Frankenstein-rewrite and dramatically increases the chances of "never getting finished".

Re: The Lone Developer Problem

#110

Post by bigpeopleareold » Tue, Feb 28, 2023, 10:02 AM UTC

fredsted wrote: post #92

I've often noticed developers seeing a project for the first time and not long after proclaim it as "bad code" and that it needs to be refactored or rewritten (with zero thought as to whether it's good for the customers or the business.)

Heh - I understand that impulse, but when I thought that, I think I was less rational. Why is it bad? I have seen bad codebases (whether for real or imagined cases) but to unravel something that is bad can be a real big chore. There was one case where I felt and still feel a certain project was overly-engineered, but rewriting it (which I took a little time doing) is a lesson in futility, particularly if there is no real technical or business impulse to partake such a mission.

From experience, those announcing that a codebase is bad sounds more resume-driven than technical. It sounds like they want to make a mark more than making a functional difference. "Bad code" that happens to have a knowledgeable team around it is not that bad, it's just not understood by outsiders immediately. Also, given the rate of turnaround in teams and companies, making large and significant rewrites and changes would probably not tend to be seen through to their fullest conclusions, in that one sees the long term effect of a large rewrite.

I think if a codebase is actually bad and if codebase aesthetics are an important aspect to one's career, finding the next company with a potentially better codebase is probably a better thing to do than blanket and uninformed critiques about other people's work. :)