7 ms·

From the article: “Can I take some time to clean up this code? It is horrendous.” The answer should always be yes to this question. No, it shouldn't. This enti

From the article: “Can I take some time to clean up this code? It is horrendous.” The answer should always be yes to this question. No, it shouldn't. This entirely depends on the long-term prospects and importance of the code. Assuming that your boss is doing his job, he might understand the trade-offs between having you doing 'code gardening' in subsystem A vs. building new functionality in subsystem B. He may even understand them better than you. Mileage varies, of course, depending on Pointy-Hairedness.

orblivion 16y ago
I agree, this seems to be based on the feeling some of us have that code has to be "done right", forgetting that the code isn't there for its own sake (at least in a job setting). The bottom line is really what matters in the end, and your boss is closer to that than you are. On the other hand, coding efficiently in the long term will likely sometimes be good for the bottom line, and you are closer to your code's efficiency than your boss. So one should make sure to understand why the boss wants to make a certain call.
- nikster 16y ago
  I guess you could say: Make it good. Just don't make it _too good_. Not all code needs to be super general, extensible, and re-usable. However, all code needs to be simple and elegantly designed, and unit tested. It needs to not smell.
cdevroe 16y ago
I think the perspective I was taking in my post was that many bosses do not fully understand the inner-workings of the codebase for their own product and they also don't need to maintain it. So developers truly are the best person to help weigh the need for maintenance. Of course, there are bosses that fully understand all of this and if you're lucky enough to work for one - awesome.
- Stormbringer 16y ago
  Fundamentally it is a deeper problem. If you have to put your hand up in order to be allowed to go to the loo, you are not in an environment that respects human dignity. If you have to ask permission in order to do the right thing then you are in an environment that is ethically deficient. Moreover, despite everybody claiming to value success, it is likely that your definition of success is significantly different from the PMs definition of success. Their definition of success is likely to be something like "all activities marked as completed and on time", whereas your definition of success is likely to be something like "the bloody thing actually works properly". This is why testers have such a sucky job, because they always come under pressure from the PMs to give the final sign off on something that they know isn't working properly or 'good enough'. Testers that do their job properly and stand up to the PMs are in danger of losing their jobs. This is why testers need an 'advocate' that has at least as much political clout as the PMs (if not more so - if the PM is putting pressure on the testers to sign off on a crappy product, it isn't the testers who should get sacked...)
  - halostatue 16y ago
    When I—a development manager who still works with the codebase—tell my guys that I don't want them working on that particular piece of code it's precisely because a) I know things about the overall design and project that they don't, and b) I know what needs to be done next. Yes, I want my employees asking whether they should be spending the extra time to make something subjectively better. Once the code works, we need to weigh the time it will take to clean the code up vs the time to do the next task. Code cleanup should NEVER be a sole task, and it should probably not be a solo task if it is (and if it is, it had better be one of your two or three best programmers in the company doing it). I have told folks not to make changes NOW, because we are revisiting the code in two sprints for the next major milestone. Meeting the current milestone is more important than aesthetics, and it isn't an ethical deficiency at all. (Hopefully this is sensible; composed on the iPad right before bed.)
    - Stormbringer 16y ago
      Let me be clear - I think that before programmers start throwing off their shackles and asserting their 'rights' they need to build up trust with the PMs. I do this by consistently delivering high quality code on time and reporting back to them about progress. I assure them that I'm not going to drop them in the crapper by trying to conceal a problem until it is too late, I am very up front and honest about any problems and try to give them plenty of advance warning. In return, I expect to build trust and the coinage of the realm is autonomy. They show me the plan, and I figure out the best way to get us across the line relatively unscathed.

orblivion 16y ago

I agree, this seems to be based on the feeling some of us have that code has to be "done right", forgetting that the code isn't there for its own sake (at least in a job setting). The bottom line is really what matters in the end, and your boss is closer to that than you are. On the other hand, coding efficiently in the long term will likely sometimes be good for the bottom line, and you are closer to your code's efficiency than your boss. So one should make sure to understand why the boss wants to make a certain call.

nikster 16y ago
I guess you could say: Make it good. Just don't make it _too good_. Not all code needs to be super general, extensible, and re-usable. However, all code needs to be simple and elegantly designed, and unit tested. It needs to not smell.

cdevroe 16y ago

I think the perspective I was taking in my post was that many bosses do not fully understand the inner-workings of the codebase for their own product and they also don't need to maintain it. So developers truly are the best person to help weigh the need for maintenance. Of course, there are bosses that fully understand all of this and if you're lucky enough to work for one - awesome.

Stormbringer 16y ago
Fundamentally it is a deeper problem. If you have to put your hand up in order to be allowed to go to the loo, you are not in an environment that respects human dignity. If you have to ask permission in order to do the right thing then you are in an environment that is ethically deficient. Moreover, despite everybody claiming to value success, it is likely that your definition of success is significantly different from the PMs definition of success. Their definition of success is likely to be something like "all activities marked as completed and on time", whereas your definition of success is likely to be something like "the bloody thing actually works properly". This is why testers have such a sucky job, because they always come under pressure from the PMs to give the final sign off on something that they know isn't working properly or 'good enough'. Testers that do their job properly and stand up to the PMs are in danger of losing their jobs. This is why testers need an 'advocate' that has at least as much political clout as the PMs (if not more so - if the PM is putting pressure on the testers to sign off on a crappy product, it isn't the testers who should get sacked...)
- halostatue 16y ago
  When I—a development manager who still works with the codebase—tell my guys that I don't want them working on that particular piece of code it's precisely because a) I know things about the overall design and project that they don't, and b) I know what needs to be done next. Yes, I want my employees asking whether they should be spending the extra time to make something subjectively better. Once the code works, we need to weigh the time it will take to clean the code up vs the time to do the next task. Code cleanup should NEVER be a sole task, and it should probably not be a solo task if it is (and if it is, it had better be one of your two or three best programmers in the company doing it). I have told folks not to make changes NOW, because we are revisiting the code in two sprints for the next major milestone. Meeting the current milestone is more important than aesthetics, and it isn't an ethical deficiency at all. (Hopefully this is sensible; composed on the iPad right before bed.)
  - Stormbringer 16y ago
    Let me be clear - I think that before programmers start throwing off their shackles and asserting their 'rights' they need to build up trust with the PMs. I do this by consistently delivering high quality code on time and reporting back to them about progress. I assure them that I'm not going to drop them in the crapper by trying to conceal a problem until it is too late, I am very up front and honest about any problems and try to give them plenty of advance warning. In return, I expect to build trust and the coinage of the realm is autonomy. They show me the plan, and I figure out the best way to get us across the line relatively unscathed.