How about not spending your weekends on fixing bugs that could have been easily predicted and not rushing because you underestimated the time you w...
For further actions, you may consider blocking this person and/or reporting abuse
About estimates: The best answer is: "I don't know (yet), Let's talk about it tomorrow."
This comunicates it's hard to estimate.
It also gives you time to think about it. Even if you don't: the things you know can settle and you get a clear perspective.
Keep in mind: You are the professional expert. They want to know something from you. So if it is your professional opinion that you can't answer that yet, they have to take it. Otherwise they shouldn't have asked you in the first place.
Be a professional. YOU own this conversation, because you ARE the Expert.
One that Steve McConnell recommends:
Do you want an estimate or a commitment?
An estimate looks like this: 4-6 months
A commitment looks like this: we'll have it deployed to customers by 5pm on the 12th of December.
That's right :)
Great points! Thanks for sharing your experience with f*ups, as it's not always easy to talk about them 😃
I think it's also very important not to try to decrease the feature estimates just to satisfy some pressure that it shouldn't take so much time. If you know something will take time, just estimate it as it should. If you decrease it and rush through the implementation, you expose the code to f*ups and increase implementation time thanks to all the bugs it will create 🙂
These are very good suggestions.
Don't deploy on Friday, is a big classic I think.
Loved it to always test things. Usually more complex projects can have 2/3 environments before production as dev, QA, tag, production.
And about backups, they could be automated, maybe with a notification system if something goes wrong.
If you are alone in project, you need to think about everything, but making more environments are the best way to test things :)
Most cloud providers have options for automated snapshots/backups. They really safeguard you in the events of ransomware attacks and the likes!
My two cents...
Never take an error message for granted because you know how to apply a workaround on the server.
Yep... Makes sense in retrospect. But since I'm the only one to deploy the code to acceptation and production, I did know how to apply these necessary changes. But this time, update scheduled to run automatically at 8pm, because of personal circumstances I totally forgot to check the production environment after the update. And because these personal things made their way into the early morning, the production environment was down for over an hour. My colleagues did a good job in fixing things, and I was able to help them a little by chatting from a distance, but it really felt bad...
And in retrospect, the acceptation environment already had this error for a longer period.
The fix was really simple. That day, we did an extra update of production with this fix. And it went flawlessly.
I think most of these f*ckups are related to the good old "assumption... is the mother of all f*ckups". Yep, including mine.
Thanks for your stories/tips as well @michal_emphie
Yep you got right, assumption is the worst
One of my big fuckups- Some years ago, I was working as the front-end developer at an e-commerce service company, providing smaller online retailers with recommendation services. The way it worked was that we loaded, on each client page, a JS config file containing client-specific customizations, a platform-specific library, and a file containing the core functionality. This also predated JS build tools as a real Thing, so we had to load each file separately rather than a single bundle.
Well, one day I was asked to add a certain feature for a particular client; this was a simple thing, just converting a piece of data from some computer-readable form to something more human-friendly, so I just put the function in the platform file and put the lookup table it referenced in the core, so it'd be available to other platforms if they needed it. It all worked fine, so I uploaded it to our CDN and waited for the change to propagate out.
A few days later I got a call about our code breaking that client's site. Apparently the new platform file had propagated out, but the core file hadn't, so when my new function went looking for its lookup table, it couldn't find it and broke the website of actually our largest client.
Lesson learned:
Yep, learning on own fault's is really hard thing, I'm glad you have found any conclusions after this :)
Great article!
Let me share one fuckup of my own in return.
I've been deploying WordPress plugin to repository with important change to database schema. I've consulted it with other developers in my company, as it was supposed to be a bit longer operation, but executed only once, directly after plugin update. It all went well during QA, new version seamlessly introduced change and acknowledged that update has been made and isn't required anymore - as expected.
I did not take into account one matter. Instantly after plugin update there may be multiple requests during period between dispatching changes to database and storing the info about successful execution. Enough to trigger the same change more than once, resulting in never ending process, usually finished by PHP timeout instead of expected flag about completed migration.
Well, it have influenced some website owners, fortunately not a large amount (out of around 10k users) as the bugfix was introduced at most an hour after first deploy. Nevertheless, I managed to DDOS not only some of our users, but also main website of my own company 😅
What did I learn? When it comes to database, always proceed with the highest caution and generally befriend with mutexes.
With Wordpress plugins you need to be really careful :)
Very useful thanks for sharing
Hey there can you help me with php and my sql connection with website