In the many development teams I was working in was a period when some manager urged "Folks, now it is not the time to write pretty code, let's get the simplest code as fast as possible out just to test if customers need this!".
No need to overcomplicate it, don't cook anything fancy, just feed the customers! Just like you throw together potato, bacon, eggs and onion in a pan and that's it! (Result is parasztreggeli 👆 - a food you won't hear about).
What they mean is to write code poorly and only fixing it when the feature proves its existence. They usually reason about it as justified technical debt, but to quote George Fairbanks quoting Ward Cunningham:
“A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.”
In my own experience I find it hard to write code poorly. When I try not to think in advance I usually lose myself in a web of half-baked, contradictory code. Then I get frustrated, delete some it and start writing pretty code, then I remember, "Hey, this is exactly what we are not supposed to do!", then I am trying to hack it again.
The result: bad code that took I think as much as or more time than writing normally with a horrible mood as a side effect.
In other words I don't have the expertise to understand problems enough not to shoot myself in the foot, but not enough to write "pretty code".
Discussion: What is the quickest way to write code?
What are you doing in these circumstances? There is a huge pressure on the development team, it was promised (without them) to the higher management, that feature X will go in beta testing by this and this date and you can't write pretty code?
Is there a trick to this so I can actually write throwaway code faster than writing average code?
Or at least let me know if I am the only one struggling with this 😳😅.
The only time I managed this requirement working was when the task at hand was small and specific enough that you can just copy-paste a new version of your code, modify it and see how it performs as an A/B test.
Top comments (8)
I haven't read
Clean Agileby Uncle Bob, though I am very well aware of clean code movement (see my articles previously here).I was actually curious if doing the "ugly, throwaway code" possible faster than the average code for somebody who know how to write the right code.
I never knew how to convince people that we can't go faster a certain pace; that if we do we go slower.
What if it was my inability to see an incompetent leadership?
(Currently I work in a very-very small engineering team - there is no one else to blame and these questions are just my way to process my previous workplaces).
You are right on track. It always takes 2.6 to 3 times as long to fix rotten code as it would have to do correctly on first place. I run into this all the time. The problem I see with rotten code is that it only works 'in the here and now'. I know "rotten" code may be ok to get client side approvals. But that is very few clients. If the analysis phase and 'design' phase are done correctly, rotten code never sees light of day.
I agree. To make it clear I meant that you rush your code to the point that you get confused what your own function 15 minutes ago exactly did. So I say even writing it takes more not to count fixing it.
Once my team got 6 new devs for a week to rush some features... The lead of them promised the code will be shipped the next night. Of course a rush like this will leave a rotten pile of code.
OMG, this cover image :D :D :D
Cover image => successful post. Oh shit, I have forgotten the emojis. 🥺🧔
if your logic is solid and your programmer can actually touch type, it will result in reasonably faster code... what the programmer thinks has to flow from his fingers.
It does flow, but only if I have enough time for it.
Fair enough. How would you prepare the data for this?
You would need some kind of a stat for this, I presume? That I have found always very-very hard to produce.