I kind of disagree on point 3. So far in every company I worked for, in the first phase we always write a quick and messy poc to see if our idea is indeed achievable. Once the second phase gets approved, I always had the opportunity to refactor it properly. In rare cases when the pic is an insane mess, I was always aloud to start from scratch. No one willingly wants to write shit code.
You're lucky! Most places I've worked see a POC and want to rush to the next step.
That's why it's important for us as developers to manage up. We need to advocate for some extra time to do POCs the right way because it most likely become production code
The only complains I have from our process is that a. the poc allocated time spans between 2 to 4 weeks in order to decide whether a ~2 years project is feasible... b. between the poc and the actual start of the project there is barely enough time to properly design it. Thus following certain practises as the article suggests is highly recommended
As of lately though things have improved by a lot.
Hi Stefanos, thanks for your comment!
To be honest, I never worked in a company that followed that kind of process. I don't doubt it works for you and your team. But, in my opinion, writing a fast POC and using clean code principles are two things that can easily coexist whitout interfering with one another. Once you know naming your functions correctly is important, why would you do otherwise? How would that speed up the process?
The third point is specially important when you work with beginner devs in the same team. After all, every code you leave for them to work with serves as example. Checkout the broken windows theory (mentioned by @eidsonator
in another comment).
You have a point on naming. But naming is the least of the problems and by far the easier to amend. I was referring about concepts like SOLID principles, well thought abstractions, patterns etc
Just wanted to state a counter-argument here, and say that point #3 resonated with me more than any other.
I am currently refactoring a code base for a client that is outrageously messy. And why? Because the original developer was messy and the people that followed him just copied his style. Now we have huge functions, one of them 1400+ lines long.
I guess I should not complain. They are paying me very well to clean it up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I kind of disagree on point 3. So far in every company I worked for, in the first phase we always write a quick and messy poc to see if our idea is indeed achievable. Once the second phase gets approved, I always had the opportunity to refactor it properly. In rare cases when the pic is an insane mess, I was always aloud to start from scratch. No one willingly wants to write shit code.
You're lucky! Most places I've worked see a POC and want to rush to the next step.
That's why it's important for us as developers to manage up. We need to advocate for some extra time to do POCs the right way because it most likely become production code
The only complains I have from our process is that a. the poc allocated time spans between 2 to 4 weeks in order to decide whether a ~2 years project is feasible... b. between the poc and the actual start of the project there is barely enough time to properly design it. Thus following certain practises as the article suggests is highly recommended
As of lately though things have improved by a lot.
Hi Stefanos, thanks for your comment!
To be honest, I never worked in a company that followed that kind of process. I don't doubt it works for you and your team. But, in my opinion, writing a fast POC and using clean code principles are two things that can easily coexist whitout interfering with one another. Once you know naming your functions correctly is important, why would you do otherwise? How would that speed up the process?
The third point is specially important when you work with beginner devs in the same team. After all, every code you leave for them to work with serves as example. Checkout the broken windows theory (mentioned by @eidsonator in another comment).
You have a point on naming. But naming is the least of the problems and by far the easier to amend. I was referring about concepts like SOLID principles, well thought abstractions, patterns etc
I see what you mean. I suppose is about balancing between good and clean practices and simple enough implementations.
As long as you set the expectation that version 0 is intended to be thrown away from day 1, this works.
If on day 120 the team figures out this unspoken assumption isn't shared, things fall apart.
Just wanted to state a counter-argument here, and say that point #3 resonated with me more than any other.
I am currently refactoring a code base for a client that is outrageously messy. And why? Because the original developer was messy and the people that followed him just copied his style. Now we have huge functions, one of them 1400+ lines long.
I guess I should not complain. They are paying me very well to clean it up.