3 ms·
I believe the author has only worked at a certain type of company where his points might be true. But if you work at a place where software supports the main bu
by doix 4y ago
I believe the author has only worked at a certain type of company where his points might be true. But if you work at a place where software supports the main business rather than being the main business, I personally found that they were not true.
At my previous gig we always had deadlines and we never missed them (technically, stuff gets de-scoped). Before a project is even started, time is spent doing a "feasibility study". The hardest problems are usually solved then (in isolation), tech stacks are evaluated and chosen, any hard algorithms are written and bench-marked to see if they scale, etc.
The deadline is padded to hell to allow room for stuff to slip and scope is clearly defined. If/when development starts to slip, stuff gets de/re-scoped pretty quickly to make sure things do hit the deadline. The deadline was pretty much never arbitrary, it would depend on when a different project(not software) would start/finish so that the next one could use it. If all hell broke loose and the deadline was somehow too optimistic, then the deadline would move to the next time it was a good time to launch the software, not just a few weeks (since no one cares at that point).
A specific example, we made a tool to analyze production test data for semiconductor devices. tl;dr a few thousand devices per wafer, _many_ production wafers, _many_ tests per device, basically "big data" (trillions of rows). We spent a few months evaluating different databases/schemas until we found one that worked. We knew pretty much all the queries that people would want to run against the data and made sure they would be fast.
The tool was meant to replace a vendor tool we paid for. The deadline was for when the contract was meant to renew. If we missed the deadline, the deadline would have moved to the next year (next contract renewal). This wasn't a software company, a lot of processes were pretty messed up, but the stuff the author complains about was pretty good. Probably because it was a semiconductor engineering company that always hit deadlines to get stuff to the fabs on time.
The downside is of course is that you are a "cost-center", not great for career development.
- laserlight 4y ago> At my previous gig we always had deadlines and we never missed them (technically, stuff gets de-scoped) I call those “deadlines” time boxes. I believe that the industry would greatly benefit from distinguishing the two.
- doix 4y ago> I call those “deadlines” time boxes. I believe that the industry would greatly benefit from distinguishing the two. Interesting, I've not heard time box used in that context. I've seen it used to limit the amount of time you spent on something. So if there is some tricky bug, you would timebox it to 3 days one week. Regardless of if you fix the bug or not, you stop working on it after 3 days even if you don't deliver a fix. In what I was talking about, you still delivered _something_, it might just be less than what was (initially) agreed upon. Normally it's polish/ux niceties that don't make the cut and then come in a later version.
- laserlight 4y agoAh, OK. If you came back to the dropped scope, then timeboxing wouldn't be the best term to describe it.
- kayodelycaon 4y agoDeadlines are fine when scope can be reduced. My experience with deadlines is that scope only increases. In fact, I've frequently been expected to deliver something substantially different from what was estimated without changing the deadline.