[dahart]

In my ~25 years of professional software development, the single biggest factor in productivity for me has been whether I was involved at the start of a project. Knowing the initial design decisions, and being comfortable changing anything, allows me to be orders of magnitude more productive than when I'm diving into existing code designed by someone else.

I saw this perhaps most acutely with a company I sold - for a couple of years I was more productive than on nearly any other large software project I've worked on, because I knew the ins and outs of everything. The developers who bought it and took over are probably better developers than I am, and they are unquestionably excellent coders, yet it took a couple of years for them to get productive at making even medium sized changes. It became incredibly obvious to me how handicapped you are diving into something someone else made, especially if the original designer isn't there anymore.

Meshing really well with managers & PMs is probably the next biggest factor in my own experience, but it doesn't come even close to the gap between being there from day 1 vs coming in much later.

> Productivity tracking tools and incentive programs will never have as great an impact as a positive culture in the workplace.

I'm a fan of choosing to use time management apps and productivity tools to manage my own budgets. But I admit that I hate it when I have to do it for someone else.

[bit_logic]

One of the most powerful benefits from being there since the start is the complete confidence in ripping out and deleting obsolete code later. Even good developers new to the project are afraid to do this, and they should be since it's very risky without the full context.

The natural trajectory for a project is to keep adding features until it collapses from its own weight. Only the long tenure developer can fight this and revitalize a project by removing the useless excess.

[qes]

I've been with the same company and mostly leading the same software system for the past 10 years.

Feature work is such a smaller part of my individual contributions at this point - I do some here and there so I don't get too out of touch with the front end and user experience - but much of my coding work these days is reworking existing core functionality.

Thankfully we understand the necessity of deep maintenance for our system that we fully expect to still be running in 10 more years, but even with that it's damned hard to keep up. I can't imagine having developers come and go every couple/few years and little or no leadership support for code and systems improvement.

[reactor]

Couldn't agree more. I've noticed this many times in my 16+ yrs into the industry. Not recognizing this is one of the primary reason line managers letting an employee (esp those who are involved from the beginning) go, if they are asking for a raise, thinking they are easily replaceable. It really costs the company.

[BerislavLopac]

This has been observed long ago, and is known as Brooks's Law [0].

Building software is a knowledge business, and there are three types of knowledge involved:

    1. Subject knowledge: understanding of the subject the software is about (e.g. accounting when building accountancy software).
    2. Platform knowledge: understanding of the platform used to build the software (e.g. Python, SQL, React etc).
    3. Architecture knowledge, which is what the parent is talking about: understanding of the specific choices made in the development, being aware of all the Chesterton's Fences [1] etc.

[0] https://en.wikipedia.org/wiki/Brooks%27s_law

[1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...

[dahart]

These are great angles on software development and productivity, especially Chesterton’s Fence. I have watched several companies do rewrites of large codebases only to realize it was a massive mistake after taking years longer and spending millions more than intended. In every case it was a disproportionate focus on the problems they had, and a failure to understand what had been working well before tearing it down.

I’ve also watched Brooks’ Law in action, watched people thrown onto a project to try to get it out the door cause it to slow down. I do not believe what I said is an example of Brooks’ Law. Brooks’ Law is “adding manpower to a late software project makes it later", it was not an observation about all software development in all stages. Brooks’ Law assumes that the “ramp up” time is finite, and not particularly long.

I’m also not actually saying that people aren’t productive when joining existing projects, I’m saying that there’s a much deeper component of productivity that depends on involvement from the beginning. I’m sure you’ve already experienced being very “productive” after a short time when joining a large project, I definitely have. It’s the kind of productivity that depends on being there early, and Brooks wasn’t making any qualitative statement about productivity, only quantitative.

Fred Brooks was a lovely man to speak to, BTW. I met him and had a long interview when I was considering going to North Carolina for graduate school. The lasting impression I got wasn’t anything he said in particular, it was more of the positivity and optimism he carried about software and life that made me want to hang around and hear what he had to say.

[BerislavLopac]

> I’m sure you’ve already experienced being very “productive” after a short time when joining a large project

Most definitely, but that only happened when at least one of the following conditions were met:

1. There was good documentation in place and an onboarding process that made it easy to transfer the foundation of the architectural knowlegde.

2. The work was clearly delineated and compartmentalised, so understanding the overall architecture wasn't critical for at least the entry-level tasks.

3. The architecture was a simple, standard pattern I was already very familiar with: for example a Django monolith.

I'd also like to add that a better name what I called "architecture knowledge" would be "institutional knowledge", as it does not include just the architecture per se; it includes the auxiliary things like development process, testing mechanisms, deployment etc.

[freedomben]

Very much agree. It honestly shocks me that more people don't recognize this. I think as humans we just tend to forget stuff over time, as we go, and as our perspective changes.

[z3t4]

Make sure no code base would take more then a month to rewrite. That way it can be rewritten. But some tests could probably be reused, so tests should not be too intertwined with the code, tests should work independently from the code it tests.

[reactor]

Many enterprise projects usually runs multi-year, its nearly impossible to make a code base that can be re-written in a month.

[greenflame7]

How would that work for say the windows code base?

[z3t4]

I have no OS dev experience, but I like the idea of many smaller specialized programs that are able to communicate with each other. Another problem with large and slow moving code bases is that things around changes, like hardware getting better/faster so software architecture that made sense 30 years ago might not be the best solution today. An OS should probably not be developed by a single team or company, there should be an open core/kernel, then companies could instead compete and specialize in different combinations and support of systems, apps and services developed independently, where each part could be replaced.

[kwanbix]

This also applies for product management imho. At least for me it does. If I have to start a product from start it is much better than taking over another person's product.