Ever been here before...? Developer: “Hey, I just finished the feature” Product Owner: “Oh, the customer actually wanted something different. Sor...
For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
A couple of decades or so ago, I wrote some code in Occam for the transputer. Which was an interesting challenge, thinking about parallelism at every code line. What I wrote worked well, but the project needed some hardware built for the data inputs, which never got built, and eventually the project was canned.
Did you find it strange that they had you build the software when they knew that the hardware wouldn’t be available? Or did you come to terms with it?
The expectation at the time the code was written was that the hardware would be built, so that wasn't an issue.
Reflecting on your question further, when I think of my code which got thrown away for one reason or another, I don't think I mourn any of it as such. What is more a matter of regret to me are the skills I acquired along the way that I wasn't then able to exploit later. Like writing in Occam. Or the COM/DCOM/COM+ API. Or Oracle Data Cartridges.
Good point. Time spent learning isn’t wasted. I do really regret times that I wasn’t learning a ton but I still worked nights and weekends to impress new bosses, etc. I wish I spent that time with family and friends instead! :)
I worked on a multi-year government project that was developed using the Waterfall approach (as opposed to Agile). By the time the project completed, the government customer had learned so much on their end that the changes involved a complete rewrite. I couldn’t help but wish we had learned along the way with them. That’s why I write so much about continuous learning and iterating through Agile now! :)
Do you feel that your government customers now engage sufficiently with Agile? Obtaining people on the customer side with the time and skills to provide the necessary feedback in a timely manner can be a challenge, in my experience.
It depends. I have some friends who still work on government projects and it depends how risk averse the project is.
If you’re building something mission critical, it lends more towards upfront planning (which Waterfall is best at).
If you’re building something that is less risky, you can really embrace Agile. But sadly, those that started with Waterfall tend to turn Agile into “mini Waterfall”.
This might seem a bit weird to some, but I LOVE to throw away code. And not only code written by others, but especially mine.
Once I was writing a recursive algorithm to go through a tree with not only different kinds of data in it, but also unknown number of subnodes per node. I spent the whole day on it only to think of something „better“ right when I went to it the next day. Less code, less „exceptions“ (deviations from the standard path) and more importantly more flexibility!
The new code was written in two hours (or so) and could do more, than the one I just deleted whole heartedly!
And as a general approach: Code that is deleted, has no need for maintenance. And someone smart once said: the only code, that never produces bugs is code, that is never executed (or deleted).
Truth! Recursive algorithms can almost always be expressed more simply.
That being said, have you ever had to delete code that you felt was as good as it can get? Or have you ever had a project canceled that you really enjoyed?
I threw away lots of code that was as good as it gets to my abilities at the time. But since I am still learning every time I do something in code (mostly intentionally) I never feel any regret or remorse, when deleting old code of mine.
Even though I might have done it similarly, I never get attached emotionally to code I produce. I code, because I like solving problems and the challenges that force me to learn.
So even though I threw lots of code away in my personal or professional life. I never felt, that I am destroying something invaluable. It‘s a means to an end. And if that end is reached, it can go.
Maybe IF I wrote an AI sometime in the distant future, that shows human treats, I could not, but so far... I always loved hitting the delete button.
But if I had to pick something, I'd choose a BER-Parser-Implementation, that was never used. I just wanted to see, if I can do it and used it at one point in my own code, which was superfluous, when we chose Azure-ADFS for authentication.
Others prefered the one from BouncyCastle or just dont want to have anything to do with certificates.
And I guess, there is another exception, which I wrote about already here: dev.to/andreasjakof/brilliant-but-...
It was wrong to do it this way, but still ...
I'm right on the cusp of deleting thousands of lines of code and templates from my documentation engine, Orchid. It's some of the oldest code in the project, focused around calling external documentation tools like Javadoc so that it can make much nicer code documentation. And I can't wait to finally go live with this and remove all that old cruft!
I have abstracted those portions of code into a separate library, and the process for adding new languages now involves modifying that library and writing a tiny adapter from it to Orchid. That's it! Previously, each language needed its own set of HTML templates and a lot of boilerplate to call to these external tools, but now they are all the same code underneath, just going through these adapters.
Moving forward, it will be significantly easier to support new languages since I don't need to write nearly as much boilerplate, and don't have to worry about new templates at all. Plus, since the documentation-formatter no longer needs to know about Orchid, it is easier to maintain since it's just pure data now. A very clear separation of concerns makes this whole process much better, but it has been quite thr journey to get to this point!
Yes! You nailed the point. Old code needs to go so new code can live! :)
I wrote a multiplayer socker game at around 2008 in flash and java.
Back then I was fairly green, so it took too long and my boss ended up pulling the plug.
In retrospective I was not ready for that kind of task either. :)
I’ve become too numb to stay attached to code these days... :)
Yea it’s tough to find the balance of caring enough to do a good job, but not caring so much that it causes you pain.
It happens to me quite frequently, probably because I'm the idiot that jumps into writing proofs of concept before I forget the daft idea I just had - if I code it then I'll remember it.. yeah right :)
Recently - I threw away a SOAP 1.2 WSSecureConversation emulation (bit specific I know), that was intended to support legacy customers while we migrated our stack to .NET Core from .NET Framework. Written because Microsoft did not support their flagship SOAP library (WCF) on server side .NET Core. Until March. Now I get to ditch my hack and use theirs again
A long time ago, and less 'throw away', more 'left it somewhere': I had written an entire x86/16-bit kernel as a learning experience, and was pretty pleased that it booted and did stuff! My code was backed up to 0.25" tape (QIC-150 in fact) and safely stored in the fire safe at work. Then I changed jobs, and changed PCs, and... it was gone.
I bet you’re pleased to not have to maintain a custom SOAP library anymore! :)
Btw, I have also lost valuable things on old PCs (in my case it was a song I recorded with an incredible cellist). It always hurts. But as Thich Nhat Hanh says, things are beautiful because they are temporary! :)
Great prompt here!
The set up reminds me of the writerly phrase "kill your darlings".
Thank you. Yes, I think a lot of us could benefit from the "kill your darlings" approach. If the user doesn't need it, then delete it! :) My writer friends often cite that quote, so thank you for the reminder @michaeltharrington .
But it's still hard to remove it or to say goodbye to the hours it took to build the thing. That's why I'm hoping this thread will help others come to terms with "the loss" of the investment.
I know that it's a lot easier to part with a project if I maintained good work-life-balance while it was being built. I was mostly only ever sad to see "a darling" go if I had worked on it during nights and weekends.