141–150 of 159 posts
Earlier quoted context omitted.
Sorry, still don't understand. Are you saying that without communicating progress there is no person who understands the context in which the issue is being worked in? That doesn't make sense to me and seems to be totally orthogonal to any communication of progress.
So do you have a problem understanding or do you disagree?
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…
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.
Earlier quoted context omitted.
So do you have a problem understanding or do you disagree?
For now what you are saying does not really make any sense, so I can't really disagree...
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…
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.
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…
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…
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.
[1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
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…
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…
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 knowled…
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.
Earlier quoted context omitted.
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.
How would that work for say the windows code base?
love the classic 'are story points hours / no / then wtf are they' conversation when PMs intro jira + cousins have never been sure how summing together something that is supposed to have no relationship with time magically provides an estimate of anything also not sure why teams are using the central source of truth for progress as the 'daily todo list making' tool I live in the real world so I estimate in hours
The answer is in the article itself. It gives you real historical data so you can predict how long the project will take with evidence, rather than just a feeling, hope, or guess. > Velocity is an aggregate measure of tasks completed by a team over time, usually taking into account developers’ own estimates of the relative complexity of each task. It answers questions like, “how much work can this team do in the next…