0

I recently had a project that I took me 4 months to do , I hit some very significant bugs that where impossible to track down. I said this code is absolute garbage and started from scratch, drank a monster and got cracking, people tried to distract me but I persisted. I sent the code to QA and I personally tested all the 14 pages of errors we had, they where all gone, I found and implemented the silver bullet in zero time flat.

How should I explain to the team that my code was not good (garbage) and that I cost them 4 months of scrum team time for nothing. I’m sure that if I were to do this fresh and used the same pattern it wouldn’t take me only 2 days because of how much I learned along the way but does anyone have any thoughts? I also now live in fear that this code is somehow bad even though I have vetted it with unit test from the previous implementation, truth tables and other devs.

Chris Johnson
  • 27
  • 1
  • 4
    Career and educational advice is off-topic for this site. But fwiw, finding the current solution didn't require just "2 days", it took "4 months plus 2 days". Note also, the fact you have the idea of having to explain something to your team means your team's code review process must be broken or non-existent, and that's the real issue here. There should never be a need to explain some code "after four months" with a sane code review process, since it makes sure your code has been reviewed already by other team members. – Doc Brown Sep 02 '23 at 13:49
  • @DocBrown I thought this Software Engineering section was much more open to these kinds of questions as I saw some career advice questions asked before. We do have a code review process however, like you said my code to a senior dev that has other priorities was looking “fine” and we talked on a daily basis about changes I was making with not only that developer but others and discussed on a bi weekly basis if the current path needed substantial changes, It wasn’t until my critical critique of my DRY principles #pragmaticProgrammer that I was able to solve the issue. So I would say your right. – Chris Johnson Sep 02 '23 at 13:59
  • 3
    I guess the "career advice" questions you found were from the old times before 2016 when the site was renamed from programmers.SE to softwareengineering.SE, and the "on topic" definition was narrowed down. Also, have a look at the "teamwork" tag description. And when you discussed your design through th 4 months reguarly with your colleagues, noone can blame you that you did not "see the light" earlier, because rest of the team did not, either. – Doc Brown Sep 02 '23 at 14:19
  • The "Extreme Programming" community had the idea of a [*spike*](https://en.wikipedia.org/wiki/Spike_(software_development)): a time-boxed experiment in which you prototype something or validate an idea, then throw it away and plan the next step with this new knowledge. It seems you did a lot of experimenting. In the future, it could be helpful to recognize when you're experimenting vs implementing, so that you can maximize their effectiveness, and also to cut them short / start over if they aren't working out. But as long as you were open with your team about your progress, there's no issue. – amon Sep 02 '23 at 17:01
  • This might be more appropriate for The Workplace, since this question is focused on a people problem and not an engineering problem. To be honest, the answers from that community will probably be better. – Greg Burghardt Sep 03 '23 at 00:37
  • I disagree that this is seeking career advice. The engineering answer to this is all code is crap. No code is sacred. Write better code that sells itself. Do that and there is no people problem. But If you want to know how to sell worse code take that to the workplace. That’s a sales issue. – candied_orange Sep 03 '23 at 01:24

2 Answers2

5

Code doesn't take very long to write.

What takes time is for the developer to make their own understanding, necessary to write the code correctly. Months isn't an unreasonable amount of time, if you're working on something unfamiliar.

It's also not at all unusual that the first iteration of some code which may have taken months to analyse, can be rewritten by the same developer in a much shorter period to a much higher standard.

This is because the cost of the developer making their understanding is already sunk, and their final understanding is likely to be clearer and simpler than that embedded in the initial version of the code.

The second version of the code therefore reflects a fresh written work, corresponding from the outset to a better understanding than that on which the first version was based.

The first version, meanwhile, likely had some key features of its structure fixed when the understanding was poorer, and then had likely been adjusted incrementally in a more local way to try and drag it along with the changing understanding of the developer.

These accumulated incremental changes which fail to make crucial wide-ranging alterations, and the muddled correspondence that ensues between the code and developer understanding, is basically the problem with "legacy code".

It's why Fred Brooks said "write one to throw away; you will anyhow", because developers are rarely applied to something they already fully understand, and making that understanding almost invariably involves writing code more than once.

Steve
  • 6,998
  • 1
  • 14
  • 24
1

It sounds like you’re describing a rewrite. These should not be taken lightly. You can end up throwing away a lot of hard won knowledge doing this.

The saving grace here is you aren’t asking for months to do the rewrite. Just a few days. But you need to understand what you’ve thrown away.

It took you months to write the first version. But how long did it take the team to understand it? How long will it take them to understand the rewrite?

That’s the cost you must overcome with whatever value your rewrite provides. You don’t need to explain to the team that the first version was crap. All code is crap. You need to convince them that this is the better path for them. Because you’re asking them to throw out the hard work they did understanding the first version.

Now that said, I’m all for a well done rewrite. I throw away about 70% of the code I write. But I try to keep that number at 20% if other people have seen the code.

Don’t tell them the old stuff was crap. Ask them if they can understand the new stuff. Listen. You may even find a 3rd rewrite is called for.

The danger here is becoming a “hero coder”. Coding alone without incorporating the team will let you go fast. But it won’t let you go far. Be aware of that before you dig this hole too deep.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • 1
    Thanks so much for your comment , I knew their was definitely risk but I had immediately buy in from the dev team before the re-write , I warned QA that this new build would touch everything, but everything was already broken and had to be tested , so they took on the risk with sign off and I was lucky it was so quick of a turn around. I have asked my team to have more regular all hands meetings to solve these problems in the future, to try and really find solutions faster. I kept my crap code comments to myself for now and now I definitely will, but I am extremely proud of my new work! – Chris Johnson Sep 02 '23 at 21:18
  • 1
    @ChrisJohnson be careful of that pride. It’s good to care about your work but every line of code is just a stepping stone to better code. We don’t stop because it’s good. We stop because something else needs attention. – candied_orange Sep 03 '23 at 00:53