Hah, much more boring than that. Mostly working as a rails engineer and billing a day rate. They hired me, the company name just went on the paperwork :)
When I was running it, I was marketing myself - the company was (HMRC, if I tell you to stop reading this comment now, you're legally required to stop, right?) mostly a vehicle for billing clients and "correctly and appropriately accounting for the appropriate legal tax requirements" rather than something that was actively marketed for inbound business.
One of these was mine! Very funny to keep seeing my old consulting company come up in comments whenever this hits HN :)
I never did bother with actually making it an SQL injection; it was meant to be an in-joke between me and whoever at the client with tech chops set up the billing record, nothing more :)
But you still have some risks here, yes, with a super low probability, but a company-killing impact.
In some industries - banking, finance, anything regulated, or really (I'd argue) anywhere where losing all of your data is company killing - you will need a disaster recovery strategy in place.
The risks requiring non-AWS backups are things like:
- A failed payment goes unnoticed and AWS locks us out of your AWS account, which also goes unnoticed and the account and data are deleted
- A bad actor gains access to the root account through faxing Amazon a fake notarized letter, finding a leaked AWS key, social engineering one of your DevOps team, and encrypts all of your data while removing your AWS-based backups
- An internal bad actor deletes all of your AWS data because they know they're about to be fired
...and so on.
There's so many scenarios that aren't technical which can result in a single vendor dependency for your entire business being unwise.
A storage array in a separate DC somewhere where your platform can send (and only send! not access or modify) backups of your business critical data ticks off those super low probability but company-killing impact risks.
This is why risk matrices have separate probability and impact sections. Miniscule probability but "the company directors go to jail" impact? Better believe I'm spending some time on that.
I'd be surprised if they needed backups for a few hours of downtime with (reportedly) complete recovery where no data was corrupted. There are industries where this would be required, and it's possible I guess, but neither of these downtime events were "data loss" events, just availability events for short-ish periods of time that wouldn't - for me - result in activating our DR plans.
I must admit that I do always try and maintain a separate data backup for true disaster recovery scenarios - but those are mainly focused around AWS locking me out of our AWS account (and hence we can't access our data or backups) or recovering from a crypto scam hack that also corrupts on-platform backups, for example.
If you don't have the spec, then you likely don't have a deadline, or a "project", really -- and something like this would be the wrong choice for an approach to follow.
I'd say leaving the overall roadmap (which is all this produces, at the end of the day, if you ignore the estimation piece) fuzzy and allowing the team to work that out with users/subject matter experts is the right approach, imo.
This is where the ideal meets the annoying reality of The Enterprise (tm).
I can't talk in too much detail, but in general, the deadline date was fixed through commercial contracts signed at a high enough level that engineering didn't have sight of them. The concept and commercial case was sound, but the implementation hadn't been worked out yet, when a date was set.
My strong preference would be for estimation to come first, of course, before a deadline is picked (and even then, only picked if it is really a necessary deadline), which is then based on reality, and also include some slack for unintended discoveries.
Depends how much of a perfectionist I'm feeling. For the initial development, a sharpie, index cards, and a whiteboard wall - or Lucidchart, because it's basically an in-browser whiteboard/drawing tool.
Once the project is ongoing and you'll need to account for changes, I've either done it manually (which takes an age) or handed it off to PM's to oversee using either MS Project, airtable with a custom-authored set of actions/etc, or PrimaVera.
In the early stages of my career, or in startup life? Absolutely not. Very little relevance; XP/SCRUM were both covered together in a single 50 minute lecture, the rest of the PM aspects were tackling paperwork-generation methodologies like the "Rational Unified Process" and "Dynamic Systems Development Model", both of which I feel like would be _hell_ if I actually had to work within.
However, there were techniques (like critical path analysis) that as I've got more senior, started working at larger companies, and started stepping down the senior leadership path, I've started to see some applicability to. Not direct applications - they still need taking with a massive pinch of salt, and modifying for modern learnings in industry, but they do start to provide some value, even if it's just learning what the grey-hairs in the exec are used to seeing :)
That's really tough, and I'm sorry you had to deal with it.
I was lucky in that I was dealing (in both cases where I've run similar flows to this) with above-board exec teams who wanted the best quality information I could give them - even assuming that estimates are just assumptions - even if it meant having some tough conversations about scope or headcount.
Insightful, thank you! The entire project management industry doesn't have that great a "hit rate" -- consider the budget overruns for the last few Olympics, or for Crossrail.
I'm just not sure why software projects are "special" -- if you can avoid it being a project and instead make it ongoing OpEx like, for example, GDS managed for the UK in 2016, then great, you've sidestepped that, but until the entire PM industry discovers how to improve overall project management techniques, I don't see why we'd consider our industry "above" them.
I have, yes - or I'd feel a bit like a charlatan writing about it!
The problem with the real world examples is the business domain, which was hyper complex and the specific "pieces" of work I described wouldn't have been easy to grasp for most not familiar with the esoteric side of fintech that the project took place in.
So I went with a simpler, albeit contrived and more accessible example.
I think I would have popped a monocle too, had that been the real example and estimate from a team!
I tried to think up an accessible example that didn't require too much context on the part of the reader, so obviously, as you correctly point out, all the numbers are made up, and I'm trying to use it solely to demonstrate the workflow :)
Author here. I've been lucky enough in my career to hold some senior positions, and I thought I'd give a step-by-step on an approach I took with an "enterprise-scale" software project, and how I stole some techniques from university project management courses to meet with some success. Happy to answer any questions :)
I understand the desire to "do something", but the certification and testing process for something like this is how you find out if this actually improves patient outcomes or not. Sometimes "doing nothing" in a certain area gives a better outcome.
I'm glad they're advising doctors to use caution.
I have some architectural concerns about how it's built (a browser's javascript engine is not reliable enough to be used as a safety-critical alerting engine!), but I can see how it's attractive.
> the choice is between an unaffordable certified solution and not having any monitoring.
No, this isn't _necessarily_ the choice. Without a "false sense of security" that an imperfect monitoring system might instil, you have nurses and doctors actually doing rounds and checking their patients.
> Disruption always happens this way - same way Uber broke existing laws. Yes, few people will die. But this isn’t new when the alternative is even worse.
This is an absolutely horrible viewpoint to have. People dying because of "disruption" so a few companies can make a few more dollars is _never_ acceptable.
I apologise for this comment, you've done some great coding, but this scares the shit out of me.
There's a reason medical certifications are so hard to get, and medical software is so expensive.
You're storing patient information in postgres. What certifications do you have to assert that the patient data is stored securely, in line with your government guidelines on patient/medical data? There's a damn good reason this is the "holy grail" of information security certifications.
You've got critical alerting built into the browser window using JavaScript.
This "alerting" is the kind of critical thing that sometimes needs *immediate" intervention, or someone could die. What happens if your browser experiences a JavaScript error blocking processing? And your alerts don't fire?
What happens if they fire too often and you get "alert fatigue" because they're not tuned correctly or in line with the other alerts available at the bedside/nursing station?
How much testing have you done to correctly assert that you're interpreting the HL7 or other specs correctly? And aren't misinterpreting data for some conditions or types of individual?
The "throw things together quickly" startup mentality might (I stress might!) Be okay where it's the difference between nothing at all and something that can save lives, in a country like Sri Lanka, during a global pandemic, fine.
But afterwards, this is so much junk without serious thought and time put into certifying it.
Medical, Aerospace -- really, any safety critical industry where your code working or not could mean someone is seriously injured or dies as a result -- is an industry that needs disruption, but that disruption should happen slowly, carefully, and safely.