I'd argue with this a bit. I don't think that a marine needs to know what and how exactly an army solider does. Whereas in IT it's different.
Those who never worked on brownfield, those who were never been responsible to maintain a product, will never deliver maintainable code.
We all now those devs who fly from project to project without never following any product into later phases of their lifecycles. They write some code, the feature "work" and after them, The Deluge.
In our teams, we used to have a rule. You join the maintenance team first and once you felt the burden of decades on your shoulders, you can start working on new features.
I like the sound of that rule, I can't imagine a smaller company going for it but 3 to 6 months trawling through old code, weird database relations and learning about the madness of SQL jobs that are undocumented and totally hidden from view would be quite "character building" I think.
I once managed the upgrade of 6 backend nodejs APIs with about 700 end points, every single one had to be changed in someway as they all hit SQL and the SQL package we used was changing. Not a single end point had a test, I had to manually test and verify every single end point individually.
I will never not write an API response test again.
Max is a life enhancer for tech & entrepreneurship. Which seeks to blend both to build innovative products or services for the world that solves hard problems.
Yeah, it is a very good character building experience. That I just had to look at this article called The 5 stages of dealing with legacy code when I was taking over a legacy system from a outsourcing software firm.
The worst feeling is the aspect of reverse engineering that legacy system. I was scolded by the business ppl that I was bad and taking a long time on building/upgrading certain parts of the legacy system. Despite there's totally nothing given to me that is useful for development.
We all now those devs who fly from project to project without never following any product into later phases of their lifecycles.
I call these drive-by developers. They usually leave a mess.
The core of the problem is in how you run your software development process. If you run it like a series of projects with a fixed goal (i.e. the delivery of a feature), then you get unmaintainable code. If you run it as a product, you have the chance of getting maintainable code.
It is well documented that writing maintainable code is slower at first, but it will pay back big time in the future. Maintenance is easier but so it extending the product. Where with project based development you will often find yourself applying more and more ducttape and other MacGyver style tricks to keep the thing from not collapsing.
Starting with maintenance work is a good way of learning how the system is set up. You need to get an understanding of the system to know how to change it.
you have the chance of getting maintainable code
Love this, shows how hard it is to make good software. Aiming for maintainable code still only gives you a chance that you will get it
Max is a life enhancer for tech & entrepreneurship. Which seeks to blend both to build innovative products or services for the world that solves hard problems.
That's a good rule and that's provided that they know they are getting into a legacy system. As Simon and you had mentioned unless they know what they are doing and prepared for it they will fall badly. So it makes total sense to have a new developer working on maintenance before working on new features.
I understand that new systems will become legacy systems eventually. Therefore there's a need to understand and learn ways to tackle legacy systems regardless your own focus or type of work you want to do.
What I am saying is that if I were to do the same thing, say bring a developer who had worked only on legacy systems into greenfield projects like those in startups. It will be quite challenging for them to tackle greenfield project like those in a startup. Since the focus is towards speed, adaptability, resourcefulness and product market fit that you are building for.
Agreed, there are challenges joining a greenfield from brownfield but having done that myself I think the challenges are lesser - if only because most devs have started new codebases themselves for learning and side projects. It's hard to grow a side project to 3,000 SQL tables and 6 interconnected APIs and a fragmented front end.
Max is a life enhancer for tech & entrepreneurship. Which seeks to blend both to build innovative products or services for the world that solves hard problems.
Yup I got to agree on they might have a easier time to transit. I won't say that might be easy including things that brownfield projects does not contain.
Like design, business value/case for the solution your building, resources availability, prototyping and time to adapt to rapid changes 2 weeks from now or less.
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'd argue with this a bit. I don't think that a marine needs to know what and how exactly an army solider does. Whereas in IT it's different.
Those who never worked on brownfield, those who were never been responsible to maintain a product, will never deliver maintainable code.
We all now those devs who fly from project to project without never following any product into later phases of their lifecycles. They write some code, the feature "work" and after them, The Deluge.
In our teams, we used to have a rule. You join the maintenance team first and once you felt the burden of decades on your shoulders, you can start working on new features.
I like the sound of that rule, I can't imagine a smaller company going for it but 3 to 6 months trawling through old code, weird database relations and learning about the madness of SQL jobs that are undocumented and totally hidden from view would be quite "character building" I think.
I once managed the upgrade of 6 backend nodejs APIs with about 700 end points, every single one had to be changed in someway as they all hit SQL and the SQL package we used was changing. Not a single end point had a test, I had to manually test and verify every single end point individually.
I will never not write an API response test again.
Yeah, it is a very good character building experience. That I just had to look at this article called The 5 stages of dealing with legacy code when I was taking over a legacy system from a outsourcing software firm.
The worst feeling is the aspect of reverse engineering that legacy system. I was scolded by the business ppl that I was bad and taking a long time on building/upgrading certain parts of the legacy system. Despite there's totally nothing given to me that is useful for development.
I call these drive-by developers. They usually leave a mess.
The core of the problem is in how you run your software development process. If you run it like a series of projects with a fixed goal (i.e. the delivery of a feature), then you get unmaintainable code. If you run it as a product, you have the chance of getting maintainable code.
It is well documented that writing maintainable code is slower at first, but it will pay back big time in the future. Maintenance is easier but so it extending the product. Where with project based development you will often find yourself applying more and more ducttape and other MacGyver style tricks to keep the thing from not collapsing.
Starting with maintenance work is a good way of learning how the system is set up. You need to get an understanding of the system to know how to change it.
That's a good rule and that's provided that they know they are getting into a legacy system. As Simon and you had mentioned unless they know what they are doing and prepared for it they will fall badly. So it makes total sense to have a new developer working on maintenance before working on new features.
I understand that new systems will become legacy systems eventually. Therefore there's a need to understand and learn ways to tackle legacy systems regardless your own focus or type of work you want to do.
What I am saying is that if I were to do the same thing, say bring a developer who had worked only on legacy systems into greenfield projects like those in startups. It will be quite challenging for them to tackle greenfield project like those in a startup. Since the focus is towards speed, adaptability, resourcefulness and product market fit that you are building for.
Agreed, there are challenges joining a greenfield from brownfield but having done that myself I think the challenges are lesser - if only because most devs have started new codebases themselves for learning and side projects. It's hard to grow a side project to 3,000 SQL tables and 6 interconnected APIs and a fragmented front end.
Yup I got to agree on they might have a easier time to transit. I won't say that might be easy including things that brownfield projects does not contain.
Like design, business value/case for the solution your building, resources availability, prototyping and time to adapt to rapid changes 2 weeks from now or less.