Rendered at 10:03:43 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dkarl 13 hours ago [-]
The "When touching it is the right call" is the tricky part, because it contains this very subjective exception: "Every new feature costs three times what it should because of the design, and you can show the trend."
I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
stingraycharles 11 hours ago [-]
Everything about all this has always been subjective, which is what separates good engineers from bad ones. Bad ones do refactorings that add very little value, good ones do it the right way, at the right time.
It’s also why, as you become older, the more senior you are the more you start to appreciate “boring” solutions and avoid fancy abstractions. It almost always serves the business much better.
bbsnly 12 hours ago [-]
I really like your comment about "re-architecture". I 100% agree with you.
atq2119 12 hours ago [-]
To expand on this, I've found that often, the best way to make a change is in two steps: First, make the change easy (the re-architecture). Second, make the change that is now easy.
My best software development experiences have been in cultures where this way of working was common.
It is a shame that these cultures are not more widely spread; and I mostly blame GitHub: the lack of good support for stacked PRs or patch series or whatever you want to call it makes it harder than it should be to work in this way.
malux85 11 hours ago [-]
> I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (inability to change is also another red flag).
There is a small chance that there's strong logical reasons for a desire to fundamentally change an underlying technology, but the comment above says they "simply refused to become competent in ....... that the system is built on" and as a ex-google senior engineer of 20 years, I can 100% confidently say that the first step to large scale refactor is to understand and be competent in the existing system!
bluefirebrand 10 hours ago [-]
> this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring
Agree that it's almost certainly a mistake in hiring but strongly disagree that it's a negative signal in the employees mindset
Being specialized in one area is actually a good thing for many people and many roles. It's actually kind of bullshit that software companies expect everyone to be a generalist nowadays
Having strong preferences about the tech you like to use and the way you like to build is fine. Find the employers with projects and teams that match your preferences rather than trying to crowbar yourself into everyone else's preferences
malux85 8 hours ago [-]
Strong (but polite) disagree. Domain knowledge is now commoditised more than ever, the only valuable employees are intellectually flexible ones with a can-do mindset, ideally more senior ones who will also take responsibility for the final output. Thats all we hire right now.
With the exception of companies so huge that economies of scale make hyperspecialisation the sensible choice, however I ignored these because this is a startup and small-medium business community
bluefirebrand 4 hours ago [-]
Respectfully I remain unconvinced. Especially now with people thinking that AI basically does a baseline "good enough" on many things, specializing more deeply than the AI does is probably a really important thing for people
We already have a massive oversupply of generalists and AI makes that easier than ever, so idk. I think specialists are more valuable
felooboolooomba 12 hours ago [-]
With a title like that you have to back it up. It's a shallow article.
> why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before.
Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it.
But I agree, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.
shalmanese 6 hours ago [-]
> It's a shallow article.
Yeah, because it was generated by AI.
As soon as I got to "That is the pattern worth naming. Most rewrites answer to the engineer - ", I stopped reading.
eithed 11 hours ago [-]
[flagged]
_doctor_love 13 hours ago [-]
A perennial insight which has been articulated many times before. This feels like one of those stages all engineers pass through at some point in their growth journey. Chesterton's Fence and all that (or Joel Spolsky's "never do full rewrites" advice).
mark-r 13 hours ago [-]
I love Chesterton's Fence and haul it out whenever I can. Even though it's about 100 years old and the context is barely relevant anymore.
lostglass 12 hours ago [-]
[dead]
vinceguidry 4 hours ago [-]
I was hired once to be the Rails guy on a team of competent web developers, that didn't know Rails. I spent two years slowly ironing out issues with the codebase. By the time I was done our velocity had increased to the point to where a two week sprint took three days to complete. They couldn't feed us enough work. We all got pretty good at ping pong.
Until one day our dear team lead rammed a full NodeJS rewrite down our throats.
tpoacher 2 hours ago [-]
The main thing I feel this article gets wrong (or at least does not properly address) is that all the reasons provided seem subjective. Is there no objective (or at least semi-objective) process to do a cost-benefit analysis of a rewrite?
In ML e.g., there is the concept of a "ceiling analysis". I don't see why a variant of this wouldn't work here too.
darth_avocado 12 hours ago [-]
Very rarely have I heard an engineer look at a functioning piece of software and go “let me rewrite this because it’s not a language or framework I am familiar with and fond of”. If that does happen, it’s usually inexperienced (or bad) engineers.
Rewrites usually start with a gap in what is available and what is needed: missing functionality, existing frameworks getting obsolete, difficultly maintaining code because of the existing implementation complexity, costs, scalability issues, compliance challenges, etc. Most of these things serve the business more than the engineers.
jamesfinlayson 4 hours ago [-]
> let me rewrite this because it’s not a language or framework I am familiar with and fond of
I've been there at least once before and boy was that painful - I already have problems to deal with without someone from another team white-anting us with his ideas (that he doesn't need to maintain).
wl 12 hours ago [-]
The big exception to this I've seen: The functioning bit of software was written in an oddball language that was already niche decades ago and the pool of developers who are competent to work on such a codebase is exceedingly small.
jamesfinlayson 4 hours ago [-]
Yep - I was at a company that replaced something super obscure - I suspect the number of people in Australia that knew the tech was like 10 to 20. The tech was so obscure I don't think there was any path out other than a full rewrite.
A company I worked at decided to rewrite a Fortran system - I suspect that if they wanted to avoid a rewrite they could have started breaking bits off into C and mixing the languages at the linking step... but I understand their desire for a clean break - a rewrite was going to take years but a migration would have taken even longer and been even harder due to the lack of Fortran developers.
darth_avocado 11 hours ago [-]
I would classify them in the “ existing languages/frameworks getting obsolete” bucket.
bbsnly 12 hours ago [-]
> If that does happen, it’s usually inexperienced (or bad) engineers.
I agree with you. And that is where I was at that time. I did not have enough experience as a Software Engineer, nor with CakePHP — hence decided to rewrite. Mistakes were made.
dijksterhuis 13 hours ago [-]
good rewrites are good. bad rewrites are bad.
you’ll only find out which kind of rewrite you’re doing once you start it.
marcosdumay 12 hours ago [-]
There are good heuristics to guess which kind is yours.
But they need expertize in software development and knowledge of the software's context to evaluate.
Twey 8 hours ago [-]
> Most rewrites answer to the engineer - what they want to learn, what offends their taste, what looks good in an interview - and not to the company paying the salary.
One big caveat to this is that a large (and increasing) part of the value of the senior engineering hire is their taste. ‘Taste’ as honed by the software industry approximates business needs that the business doesn't even know it has. Sometimes engineers struggle to articulate ‘why’ a particular change is beneficial because they're just pattern-matching: they've seen the existing pattern break in a dozen different ways in a dozen different codebases, so now when they see the same thing again it ‘offends their taste’ — it looks indefinably wrong even though it doesn't seem to be causing any direct harm right now.
(Of course, sometimes it turns out just to be that they don't understand what's going on, especially but not exclusively for more junior engineers. Pobody's nerfect.)
cadamsdotcom 12 hours ago [-]
Never fix a bug without having first written a red test.
Never just write code. Always write red tests first.
In fact you can do even better and have your agent write end-to-end tests first as acceptance tests, have it witness them fail, then have it do red/green at the unit/component/integration level. Once it’s done the e2e tests pass, have it send the code off for linting and self-review.
If you are vigilant you’ll end up with a trustworthy validation suite. And with that (especially with e2e coverage), you can refactor and rewrite as much as you like.
gregopet 6 hours ago [-]
I've worked in projects where change was expected, so a policy of strict integration testing was introduced - test that treat the system as a black box and aren't aware of its internal structure (to a point, there is always some compromise). Every bug had to have a matching integration test. This made rewrites cheap, boring even (there is always _some_ danger of course, but the approach significantly simplified the decision to rewrite some part of the system or another).
argee 13 hours ago [-]
> I barely knew CakePHP, so every file looked wrong to me. I knew Laravel, and I loved working in it. So on my own time, unasked, I ported the thing piece by piece, swapping in Illuminate packages until the old framework was gone.
Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.
By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.
bbsnly 12 hours ago [-]
The Rust community would disagree with you.
hellisothers 14 hours ago [-]
Is this news to anybody? Feels like I should just point AI and several “foundations of software engineering” and have it churn out blog posts for each chapter.
bbsnly 12 hours ago [-]
Despite it not being news for lots of people, I am always surprised how many actually still fall into the trap. Somehow, software engineers are very opinionated people, and opinions are often a reason to begin such a journey of rewriting a piece of software that needs no rewrite.
Churning out the blog posts isn't a bad idea if it's true. Repetition isn't inherently bad.
janalsncm 11 hours ago [-]
It’s also worth taking a look at the git history of the repo. The current state is an accumulation of scar tissue, but you can see the actual reasons behind some things by figuring out why they were added in the first place.
mcv 10 hours ago [-]
> Start from the opposite assumption: the people before you were not fools.
I always do that. I used to assume they knew better than I. I've been wrong a lot about that.
plasticeagle 11 hours ago [-]
The article is AI slop, obviously, like practically everything on the internet these days it seems. Awful writing, circling endlessly around the same point. The entire article could have been a single sentence. Which of course, is how it began. As a prompt.
The article is also wrong. Or, at least, indicative of a broken relationship between management and engineering. If you have an engineer who can decide to rewrite the entire product without management buy-in, then that's an organisational and a discipline problem.
Added to which, of course, maintainability and build-ability both matter an enormous amount. Work to improve both of those things will improve the business.
shalmanese 5 hours ago [-]
What I'm curious about is why all AI written articles try to hide they were written with AI vs being open about it. I'd actually be far more willing to engage with an AI written article if the author shares the chat transcripts that lead them to the finished piece and I could load that context into my own session and ask additional questions/interrogate my own ideas branching from it.
Instead, people always try and pull the illusion as if the AI didn't exist.
bbsnly 6 hours ago [-]
I am sorry to hear the article sounds like AI slop to you.
brucejackson 14 hours ago [-]
This rings so very true. Have been in the software business for too many decades and having inherited other people's code many many times, there is always the decision about what to do going forward. Leave it running, refactor it gently or rip and replace. Each has it's own set of traps that need to be carefully considered.
blinkbat 14 hours ago [-]
serving the engineer _does_ serve the business, ultimately.
vjvjvjvjghv 13 hours ago [-]
Not necessarily. I have seen it plenty of times where a new contributor/manager comes in, declares all existing code is crap and needs to be rewritten to their favorite language/framework/cloud provider.
A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
yallpendantools 12 hours ago [-]
> It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
Amen! Code is never written in a vacuum. Code is never shaped only by engineering but by business and organizational compromises as well. I hate those guys who declare we absolutely must do sweeping changes to the codebase/architecture so that we are in line with the latest best practices after spending an hour with the codebase. As if the guys who spent the last 3+ years staring and building on said codebase didn't know any better (unless of course you were hired specifically because you ought to know better!).
dijksterhuis 10 hours ago [-]
> A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
it’s not always a safe assumption.
planned a full rewrite of a product at last company. i knew things were fucked 3 months in. i started really planning the rewrite 1.5 years in.
that year taught me just how fucked it was: bugs galore, race conditions, crashing frontend, testing in customer environments, data loss, rolled their own security (users from any group could login to any other instance).
previous big brained devs really fucked it and there wasn’t much of anything to show for it.
i fixed a bunch of it. but it still needed a rewrite because they had built the wrong thing. which was the bigger issue i realised 3 months in.
sandeepkd 12 hours ago [-]
> It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
The motivations and goals back then could have been different, specially in the case of MVPs
bbsnly 12 hours ago [-]
A friend of mine is migrating the company's IaC to TS as we speak because a new manager who recently joined the company decided to do it with no good reason.
CognitiveLens 13 hours ago [-]
This is my thinking as well. Although the 'never do full rewrites' rule is canon for most of the software world, I have led rewrites of two large front-end applications to great success - replacing an app that 'worked' but took an order of magnitude more time to iterate on than the codebase that replaced it.
That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.
rrvsh 9 hours ago [-]
I do feel like rewriting a front end that depends on the same backend is much less perilous than the alternative - in the end its basically just a presentation layer change
bbsnly 12 hours ago [-]
[dead]
sandeepkd 12 hours ago [-]
I think this is the key here. Most engineers go through some gradual phases from what I have learnt, initial, when they are confident of being able to accomplish everything, second when they feel they now understand how things work and third when they know that there is a lot more to it.
This essay sounds more like a second phase. Rewriting something that you do not understand makes sense if most people on team do not understand it well, and are supposed to actively contribute to it OR you are at an inflection point where the choice of architectural or foundational decisions made back then become a bottleneck in every day performance or feature development.
Business is looking it from the cost benefit perspective and they would not approve it at the cost of company time and money if it doesnt makes sense to them. Your ability to fool them for your motivations may be a different angle, still they are the ones making the call.
jghn 13 hours ago [-]
Iff the engineer's incentives are aligned with the businesses. Which is far from always true.
bluefirebrand 12 hours ago [-]
If so this is a problem on the business side, they're the one controlling a big part of the engineer's incentives
rrvsh 10 hours ago [-]
Came here to say this - you can construct a point to win this argument that needless rewrites are only for the engineer's satisfaction and serve no business need, but the article clearly argues against itself IMO. Rewriting to make it more ergonomic for developers to work with is ultimately going to be better for the business
honeycrispy 13 hours ago [-]
Right? A codebase nobody wants to work on results in a crappy, broken product.
mark-r 13 hours ago [-]
Given enough time, that describes every codebase that exists.
fithisux 6 hours ago [-]
This is not right. The engineer uses the re-write to serve business better.
Except the Rust rewrites that have been ordered directly by "business"
jyounker 2 hours ago [-]
Re-writes often do not serve the business better.
joe_the_user 12 hours ago [-]
Yahoo bought Viaweb from Paul Graham and rewrote the Lisp application in C++ and Perl. Reports are the results were strictly inferior but it achieved the goal of not having to rely on Lisp programmers.
Part of Yahoo's business is/was hiring programmers reasonably cheaply and controlling them reasonably easily - to allow Yahoo itself to sell parts or all of itself.
So things aren't quite a simple as "this doesn't serve the product", sometimes the engineers (and their replaceability) are part of the product.
breakds 14 hours ago [-]
Engineer: but business is not my problem.
yallpendantools 13 hours ago [-]
Software engineering is much easier if you assume you have no users. Except for the part where you have to make money, that is.
wmeredith 13 hours ago [-]
Unemployed engineer: business is my problem.
LoganDark 13 hours ago [-]
The business is certainly one of the most important constraints as an engineer.
13 hours ago [-]
watwut 14 hours ago [-]
> For a few weeks one summer I woke at 4am to rewrite code my employer had already paid someone to write.
I mean, if you do it at 4am, you are sleep deprived by the day two and thus unable to stop yourself from something stupid.
bbsnly 14 hours ago [-]
Only if you do not get 7-8 hours of sleep ;)
mattbaconz 3 hours ago [-]
[flagged]
joejoegobot 12 hours ago [-]
[flagged]
quardart 8 hours ago [-]
[flagged]
dude250711 12 hours ago [-]
If you commit to being around for all the support calls, then do any rewrites you want. But the rewriters unfortunately tend to use it to pad out CVs and move on.
I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
It’s also why, as you become older, the more senior you are the more you start to appreciate “boring” solutions and avoid fancy abstractions. It almost always serves the business much better.
My best software development experiences have been in cultures where this way of working was common.
It is a shame that these cultures are not more widely spread; and I mostly blame GitHub: the lack of good support for stacked PRs or patch series or whatever you want to call it makes it harder than it should be to work in this way.
To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (inability to change is also another red flag).
There is a small chance that there's strong logical reasons for a desire to fundamentally change an underlying technology, but the comment above says they "simply refused to become competent in ....... that the system is built on" and as a ex-google senior engineer of 20 years, I can 100% confidently say that the first step to large scale refactor is to understand and be competent in the existing system!
Agree that it's almost certainly a mistake in hiring but strongly disagree that it's a negative signal in the employees mindset
Being specialized in one area is actually a good thing for many people and many roles. It's actually kind of bullshit that software companies expect everyone to be a generalist nowadays
Having strong preferences about the tech you like to use and the way you like to build is fine. Find the employers with projects and teams that match your preferences rather than trying to crowbar yourself into everyone else's preferences
With the exception of companies so huge that economies of scale make hyperspecialisation the sensible choice, however I ignored these because this is a startup and small-medium business community
We already have a massive oversupply of generalists and AI makes that easier than ever, so idk. I think specialists are more valuable
> why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before.
Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it.
But I agree, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.
Yeah, because it was generated by AI.
As soon as I got to "That is the pattern worth naming. Most rewrites answer to the engineer - ", I stopped reading.
Until one day our dear team lead rammed a full NodeJS rewrite down our throats.
In ML e.g., there is the concept of a "ceiling analysis". I don't see why a variant of this wouldn't work here too.
Rewrites usually start with a gap in what is available and what is needed: missing functionality, existing frameworks getting obsolete, difficultly maintaining code because of the existing implementation complexity, costs, scalability issues, compliance challenges, etc. Most of these things serve the business more than the engineers.
I've been there at least once before and boy was that painful - I already have problems to deal with without someone from another team white-anting us with his ideas (that he doesn't need to maintain).
A company I worked at decided to rewrite a Fortran system - I suspect that if they wanted to avoid a rewrite they could have started breaking bits off into C and mixing the languages at the linking step... but I understand their desire for a clean break - a rewrite was going to take years but a migration would have taken even longer and been even harder due to the lack of Fortran developers.
I agree with you. And that is where I was at that time. I did not have enough experience as a Software Engineer, nor with CakePHP — hence decided to rewrite. Mistakes were made.
you’ll only find out which kind of rewrite you’re doing once you start it.
But they need expertize in software development and knowledge of the software's context to evaluate.
One big caveat to this is that a large (and increasing) part of the value of the senior engineering hire is their taste. ‘Taste’ as honed by the software industry approximates business needs that the business doesn't even know it has. Sometimes engineers struggle to articulate ‘why’ a particular change is beneficial because they're just pattern-matching: they've seen the existing pattern break in a dozen different ways in a dozen different codebases, so now when they see the same thing again it ‘offends their taste’ — it looks indefinably wrong even though it doesn't seem to be causing any direct harm right now.
(Of course, sometimes it turns out just to be that they don't understand what's going on, especially but not exclusively for more junior engineers. Pobody's nerfect.)
Never just write code. Always write red tests first.
In fact you can do even better and have your agent write end-to-end tests first as acceptance tests, have it witness them fail, then have it do red/green at the unit/component/integration level. Once it’s done the e2e tests pass, have it send the code off for linting and self-review.
If you are vigilant you’ll end up with a trustworthy validation suite. And with that (especially with e2e coverage), you can refactor and rewrite as much as you like.
Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.
By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.
Churning out the blog posts isn't a bad idea if it's true. Repetition isn't inherently bad.
I always do that. I used to assume they knew better than I. I've been wrong a lot about that.
The article is also wrong. Or, at least, indicative of a broken relationship between management and engineering. If you have an engineer who can decide to rewrite the entire product without management buy-in, then that's an organisational and a discipline problem.
Added to which, of course, maintainability and build-ability both matter an enormous amount. Work to improve both of those things will improve the business.
Instead, people always try and pull the illusion as if the AI didn't exist.
A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
Amen! Code is never written in a vacuum. Code is never shaped only by engineering but by business and organizational compromises as well. I hate those guys who declare we absolutely must do sweeping changes to the codebase/architecture so that we are in line with the latest best practices after spending an hour with the codebase. As if the guys who spent the last 3+ years staring and building on said codebase didn't know any better (unless of course you were hired specifically because you ought to know better!).
it’s not always a safe assumption.
planned a full rewrite of a product at last company. i knew things were fucked 3 months in. i started really planning the rewrite 1.5 years in.
that year taught me just how fucked it was: bugs galore, race conditions, crashing frontend, testing in customer environments, data loss, rolled their own security (users from any group could login to any other instance).
previous big brained devs really fucked it and there wasn’t much of anything to show for it.
i fixed a bunch of it. but it still needed a rewrite because they had built the wrong thing. which was the bigger issue i realised 3 months in.
The motivations and goals back then could have been different, specially in the case of MVPs
That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.
This essay sounds more like a second phase. Rewriting something that you do not understand makes sense if most people on team do not understand it well, and are supposed to actively contribute to it OR you are at an inflection point where the choice of architectural or foundational decisions made back then become a bottleneck in every day performance or feature development.
Business is looking it from the cost benefit perspective and they would not approve it at the cost of company time and money if it doesnt makes sense to them. Your ability to fool them for your motivations may be a different angle, still they are the ones making the call.
Except the Rust rewrites that have been ordered directly by "business"
Part of Yahoo's business is/was hiring programmers reasonably cheaply and controlling them reasonably easily - to allow Yahoo itself to sell parts or all of itself.
So things aren't quite a simple as "this doesn't serve the product", sometimes the engineers (and their replaceability) are part of the product.
I mean, if you do it at 4am, you are sleep deprived by the day two and thus unable to stop yourself from something stupid.