Timeline for How to talk to management about 'genius' code?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 27, 2018 at 14:16 | comment | added | SethWhite | @CJDennis The options were mainly examples. I'm hoping OP has better insight into the situation and can give some more specific plans than the one I've laid out. | |
| Apr 27, 2018 at 1:07 | comment | added | CJ Dennis | For option 2, I recommend reading The Mythical Man Month which explains why adding more resources slows down a project initially and might not make the time back. You're assuming that each new resource would be on the same wavelength as the OP, not have their own opinions, political agenda (backstab the OP and make promises to management that they can do the job whereas the OP can't) and not be another "genius" programmer. | |
| Apr 26, 2018 at 18:44 | history | edited | SethWhite | CC BY-SA 3.0 |
added 1 character in body
|
| Apr 26, 2018 at 15:04 | comment | added | AnoE | I like this answer because, compared to many of the other ones, it focuses on positive, concrete things to do, instead of lamenting the fate of software developers in maintenance hell. Another thing would be to spell out the need to get one of the original devs for X days for know-how transfer, to speed things up. | |
| Apr 26, 2018 at 14:55 | comment | added | Lightness Races in Orbit | With that I certainly agree. But in order to defend your reasons for composing the report and posing a challenge (as opposed to "just doing as they've asked", which would of course be their preference), you'll want to present much better reasons than subjective code quality (that, right or wrong, in their eyes "we could fix later"). That the codebase doesn't even compile without hackery is an example of a good reason. | |
| Apr 26, 2018 at 14:50 | history | edited | SethWhite | CC BY-SA 3.0 |
deleted 141 characters in body
|
| Apr 26, 2018 at 14:42 | comment | added | SethWhite | @LightnessRacesinOrbit The point of this isn't the criticism of the code. The point of criticizing the code is to establish a need for alternate solutions, and then provide potential solutions. It's a persuasive essay, if you will. Management will skim the criticism, but consider the solutions. None of the solutions should be, "I make the product viable in 2 months" | |
| Apr 26, 2018 at 14:39 | comment | added | Lightness Races in Orbit | There is the basis of a good idea here, but (as explored in other answers) fixating on subjective code quality like function names is not going to get the point across to management, when you're asking them to let you introduce a 9 month launch delay. | |
| Apr 26, 2018 at 14:38 | history | answered | SethWhite | CC BY-SA 3.0 |