For any non-trivial software project, spending time on code quality and a good architecture is worth the effort. Every hour I spend on that saves me two hours when I have to fix bugs or implement new features.
Years ago I had to review code from a different team and it was an absolute mess. They (and our boss) defended it with “That way they can get it done faster. We can clean up after the initial release”. Guess what, that initial release took over three years instead of the planned six months.
In my team we manage 2 software components. 1 of them (A) has 2 devs, the other (B) approximately 5.
Every time a feature needs to be added, B complains that it’s going to take forever, while A is done in a fraction of the time.
The difference? B is a clusterfuck of a codebase that they have no time to refactor because they run low on time to implement the features.
I work in A, but I’m not going to steal the credit, when I entered the company, A already had a much cleaner codebase. It’s not that me and my partner are 10x better than the ones working in B, they just have uglier code to deal with.
I can’t comprehend why management doesn’t see the reason A needs half the devs to do the job faster.
What they did was far beyond “agile”. They didn’t care for naming conventions, documentation, not committing commented-out code, using existing solutions (both in-house and third-party) instead of reinventing the wheel…
In that first review I had literally hundreds of comments that each on their own would be a reason to reject the pull request.
Sounds like you had a bad experience with the failed attempt at establishing agile development methods - sorry to hear that.
I just want to encourage you to give it another go with other developers that are more experienced with the methodology - in my company we’re working successfully that way for over a decade.
For any non-trivial software project, spending time on code quality and a good architecture is worth the effort. Every hour I spend on that saves me two hours when I have to fix bugs or implement new features.
Years ago I had to review code from a different team and it was an absolute mess. They (and our boss) defended it with “That way they can get it done faster. We can clean up after the initial release”. Guess what, that initial release took over three years instead of the planned six months.
In my team we manage 2 software components. 1 of them (A) has 2 devs, the other (B) approximately 5.
Every time a feature needs to be added, B complains that it’s going to take forever, while A is done in a fraction of the time.
The difference? B is a clusterfuck of a codebase that they have no time to refactor because they run low on time to implement the features.
I work in A, but I’m not going to steal the credit, when I entered the company, A already had a much cleaner codebase. It’s not that me and my partner are 10x better than the ones working in B, they just have uglier code to deal with.
I can’t comprehend why management doesn’t see the reason A needs half the devs to do the job faster.
Management cannot see beyond the next quarter, it’s a genetic precondition of the species.
The joys of agile programming…
When agile works, it actually works pretty well.
99% of the agile projects i’ve been in were waterfall in disguise (fragile for short).
What they did was far beyond “agile”. They didn’t care for naming conventions, documentation, not committing commented-out code, using existing solutions (both in-house and third-party) instead of reinventing the wheel…
In that first review I had literally hundreds of comments that each on their own would be a reason to reject the pull request.
Sounds like you had a bad experience with the failed attempt at establishing agile development methods - sorry to hear that.
I just want to encourage you to give it another go with other developers that are more experienced with the methodology - in my company we’re working successfully that way for over a decade.
[edited because the initial comment was unkind]