7 ms·

never ask for permission for things you know are vital to your work I agree to an extent. It can be easy to fool yourself about what constitutes good code --

by Dove 16y ago

never ask for permission for things you know are vital to your work I agree to an extent. It can be easy to fool yourself about what constitutes good code -- in the sense of making a product better or work on it easier. Sometimes bad code is better left as is. Even working totally unconstrained, I prefer not to refactor something unless I have a pressing reason in mind. My rule of thumb is this: as a programmer and an employee, I am professionally bound to produce quality software efficiently. If I know I can complete an assignment faster (or in equal time, but leaving behind a better code base) by rewriting something, building a tool, fixing something architectural . . . I will silently do it. No point in asking permission. It's in my charter. On the other hand, if I want to take a lot of time to rearchitect something -- an order of magnitude more than it would take to just do whatever it was that brought me there -- at that point, it's a strategic decision and management deserves to know about it. The way I see it, management has no right to require me to produce an unprofessional product in my day to day work. And I have no right to force management to use engineering considerations only in strategic decisions.

cdevroe 16y ago
Excellent points to add to this discussion. One must always weigh the time it would take clean things up. I think the main point I was trying to make with my post was; a lot of times it would take less time to just fix things than it would be to ask for permission to do so.
- Stormbringer 16y ago
  The corrollary of this is that it almost always takes longer to explain to a Project Manager why something isn't done yet/can't be done/shouldn't be done that way (etc) than it would do just to finish it or do it another way or do it properly (as the case may be).
theoj 16y ago
Then again, refactoring without permission could be a really bad idea. You need to ask yourself a few questions before you proceed. Do you have thorough unit tests for the code that you are trying to refactor? If not, be aware that there is no way to know for sure that your refactoring won't break the functionality of the code. Suppose it breaks the code. Have you thought about the operational impact to clients and the financial costs? Let's say the costs are low. How big and political is your organization? What kind of trouble will you find yourself in? As the hysteria rises, will you be fed to the dogs over this? How bureaucratic is your company and how many people do you need to interact with to fix a functionality breakage? The more people you will need to interact with, the more damage you will do to yourself and your reputation. Others will resent working in panic mode to clean up after you (now widely known as the "rogue" programmer).
- astrofinch 16y ago
  These considerations apply to a much lesser extent if you're at a shop that uses version control.
  - ryannielsen 16y ago
    Only if you're extremely confident adequate testing is in place – in any form, be it unit, smoke, user or whatever – to catch any potential regressions. Using version control does you no good if you don't catch the regression and roll back before customers are affected.
  - deleted 16y ago
    [deleted]
  - brown9-2 16y ago
    Depends how costly live bugs are
  - StrawberryFrog 16y ago
    Are there really still shops that don't? It's not like it costs money.
    - T-hawk 16y ago
      Oh heck yeah. We at HN are immersed in tech. Our experience is with companies whose core domain is tech and take things like source control for granted. But what about your local gym or sports franchise or restaurant chain or newspaper? There are millions of companies that don't have any kind of technical director or direction. Where some manager thought it would be a good idea to have a web site, and hired a programmer who's measured on how fast he can throw it together. What's a testing server? Heck, what's a server?
- igrekel 16y ago
  Not to mention if there are other people modifying the same area of code in a parallel project. They won't have tender words for you when they try to merge back their changes and find it has completely changed. Cleaning up code is a good idea but you need to be aware of the context. Always do the best you can.
Tyrannosaurs 16y ago
The other thing that needs to be considered is the total effort for the refactoring including necessary testing. As a development manager the thing that scares me isn't the small fix, it's that it takes place on a critical much used library that has potentially far reaching consequences.
- stcredzero 16y ago
  I had experience with multiple such examples. At the same time I was developing new functionality, my boss was also tweaking the libraries. So our tester kept telling me my code was broken. Then I'd look into it and find that the Strategy object used to calculate quantities in the whole app was broken. Again
- nikster 16y ago
  Have you ever heard of unit tests? It's the only solution. Unit tests, of course, are another hard sell. "what you need to spend just as much time writing tests as you did writing the code??" But I find the benefits are almost immediate, at least for new code. It's not some abstract thing down the road - it's an immediate boost to dev speed.
singular 16y ago
I mostly agree, however I think it is important to highlight that these considerations have a real-world impact. One of the biggest fallacies out there is that good software engineering is about aesthetics and somehow detached from the resultant product, e.g. 'the user doesn't care about how it's implemented' etc. - this is patently false, as code quality dictates robustness, maintainability and ability to make changes to the code base, both during development and after shipping the thing.
DanielRibeiro 16y ago
Agree completely. Also the same point of other sources: From 37 Signals' Getting Real[1]: You need people who are passionate about what they do. People who care about their craft — and actually think of it as a craft And from Software Craftmanship Manifesto[2] :Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships [1]http://gettingreal.37signals.com/ch16_Start_Your_Engines.php http://gettingreal.37signals.com/ch16_Start_Your_Engines.php [2]http://manifesto.softwarecraftsmanship.org/ http://manifesto.softwarecraftsmanship.org/
nbaumann 16y ago
I agree that producing clean code is part of our charter, but sometimes we're put in situations with close deadlines and a boss with no understanding of the importance of clean, organized and sustainable code. For example, I had a boss which would regularly check on my progress and wanted to see what I was working on and he'd say "that looks good, let's wrap it up by today", my typical response would be "it's not done, still a lot of rewriting a clean up to do" to which he'd respond "does it work? I don't want to spend much more time on this". I would then try to work really fast to clean up my code and finish up the functionality. I was forced to push through stuff that wasn't on par with my standards. I learned how to deal with this by hiding my process. I wouldn't show all of what I had. This made things easier. I still met deadlines and I felt much better about the code.

by Dove 16y ago

cdevroe 16y ago

Excellent points to add to this discussion. One must always weigh the time it would take clean things up. I think the main point I was trying to make with my post was; a lot of times it would take less time to just fix things than it would be to ask for permission to do so.

Stormbringer 16y ago
The corrollary of this is that it almost always takes longer to explain to a Project Manager why something isn't done yet/can't be done/shouldn't be done that way (etc) than it would do just to finish it or do it another way or do it properly (as the case may be).

theoj 16y ago

Then again, refactoring without permission could be a really bad idea. You need to ask yourself a few questions before you proceed. Do you have thorough unit tests for the code that you are trying to refactor? If not, be aware that there is no way to know for sure that your refactoring won't break the functionality of the code. Suppose it breaks the code. Have you thought about the operational impact to clients and the financial costs? Let's say the costs are low. How big and political is your organization? What kind of trouble will you find yourself in? As the hysteria rises, will you be fed to the dogs over this? How bureaucratic is your company and how many people do you need to interact with to fix a functionality breakage? The more people you will need to interact with, the more damage you will do to yourself and your reputation. Others will resent working in panic mode to clean up after you (now widely known as the "rogue" programmer).

astrofinch 16y ago
These considerations apply to a much lesser extent if you're at a shop that uses version control.
- ryannielsen 16y ago
  Only if you're extremely confident adequate testing is in place – in any form, be it unit, smoke, user or whatever – to catch any potential regressions. Using version control does you no good if you don't catch the regression and roll back before customers are affected.
- deleted 16y ago
  [deleted]
- brown9-2 16y ago
  Depends how costly live bugs are
- StrawberryFrog 16y ago
  Are there really still shops that don't? It's not like it costs money.
  - T-hawk 16y ago
    Oh heck yeah. We at HN are immersed in tech. Our experience is with companies whose core domain is tech and take things like source control for granted. But what about your local gym or sports franchise or restaurant chain or newspaper? There are millions of companies that don't have any kind of technical director or direction. Where some manager thought it would be a good idea to have a web site, and hired a programmer who's measured on how fast he can throw it together. What's a testing server? Heck, what's a server?
igrekel 16y ago
Not to mention if there are other people modifying the same area of code in a parallel project. They won't have tender words for you when they try to merge back their changes and find it has completely changed. Cleaning up code is a good idea but you need to be aware of the context. Always do the best you can.

Tyrannosaurs 16y ago

The other thing that needs to be considered is the total effort for the refactoring including necessary testing. As a development manager the thing that scares me isn't the small fix, it's that it takes place on a critical much used library that has potentially far reaching consequences.

stcredzero 16y ago
I had experience with multiple such examples. At the same time I was developing new functionality, my boss was also tweaking the libraries. So our tester kept telling me my code was broken. Then I'd look into it and find that the Strategy object used to calculate quantities in the whole app was broken. Again
nikster 16y ago
Have you ever heard of unit tests? It's the only solution. Unit tests, of course, are another hard sell. "what you need to spend just as much time writing tests as you did writing the code??" But I find the benefits are almost immediate, at least for new code. It's not some abstract thing down the road - it's an immediate boost to dev speed.

singular 16y ago

I mostly agree, however I think it is important to highlight that these considerations have a real-world impact. One of the biggest fallacies out there is that good software engineering is about aesthetics and somehow detached from the resultant product, e.g. 'the user doesn't care about how it's implemented' etc. - this is patently false, as code quality dictates robustness, maintainability and ability to make changes to the code base, both during development and after shipping the thing.

DanielRibeiro 16y ago

Agree completely. Also the same point of other sources: From 37 Signals' Getting Real[1]: You need people who are passionate about what they do. People who care about their craft — and actually think of it as a craft And from Software Craftmanship Manifesto[2] :Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships [1]http://gettingreal.37signals.com/ch16_Start_Your_Engines.php http://gettingreal.37signals.com/ch16_Start_Your_Engines.php [2]http://manifesto.softwarecraftsmanship.org/ http://manifesto.softwarecraftsmanship.org/

nbaumann 16y ago

I agree that producing clean code is part of our charter, but sometimes we're put in situations with close deadlines and a boss with no understanding of the importance of clean, organized and sustainable code. For example, I had a boss which would regularly check on my progress and wanted to see what I was working on and he'd say "that looks good, let's wrap it up by today", my typical response would be "it's not done, still a lot of rewriting a clean up to do" to which he'd respond "does it work? I don't want to spend much more time on this". I would then try to work really fast to clean up my code and finish up the functionality. I was forced to push through stuff that wasn't on par with my standards. I learned how to deal with this by hiding my process. I wouldn't show all of what I had. This made things easier. I still met deadlines and I felt much better about the code.