> Development is literally the simplest part of the problem set.
This is the single most important and insightful sentence that a lot of HN-ers are going to read today, and they don't even know it.
This is the single most important and insightful sentence that a lot of HN-ers are going to read today, and they don't even know it.
The contract was given to a team used to do intranet websites in classical JEE format and the letting them lose in such a project, designing as they knew.
No, of course not. But it's undeniable that these threads on HN (and other engineering-dominated forums) always include a healthy dollop of "I'd have done that better, because I'm a good software engineer" disdain. It's often paired with ignorance of how large-scale enterprise and government contracts and procurement work, what roles are necessary for large-scale projects with a significant discovery component, and what the planning process looks like when a team can't afford to launch-and-get-feedback or fail-fast-and-learn their way to a full specification.
I mean, this Deloitte project and the rollout are clearly a shitshow on a million levels. They got a no-bid contract for an eye-popping sum, then more than doubled it before the building even started! But the approaches boldly prescribed in most of the comments here wouldn't have produced a working system at the scale needed, either — only a cheaper broken one. A cheaper failure is still a failure.
This one is more insightful (in the big non-tech enterprise / government spaces). Because the takeaway for most HN developers who flip between projects should be: (1) learn how to recognize one of these projects & (2) stay away / find a new job when you do.
You'll save years of your work.
which works very well if the developers and the customer really know what they want when the project starts.
- is the scope well defined?
- do I understand the value add and agree with it?
- do I feel as if all stakeholders are aligned and adequately involved?
- do I think the team can pull it off ?
- do I think the mood and style fits myself?
- do I think the timelines and budgets are realisitc?
- do I agree with the level of transparency from management?
Etc etc
Ask yourself these questions - and more - and you will discover the answer for yourself.
In the end listen to your guts.
One important nuance: A project can be a major fail overal but a big success for you. Big check, new knowledge, rich connections...
- Does the customer have an IT org capable of fulfilling basic tasks you won't be authorized to do (app / db access, AD / rights modification, firewall adjustment, AV adjustment) in a timely manner?
- Can the customer provision necessary machines in a timely manner? If using VMs, is the virtualization team competent with their chosen platform?
- Does this project directly threaten the job of anyone whose blessing / help is required to successfully deliver the project?
- Is your leadership / your customer champion intelligent and willing enough to say "No" to scope creep when the customer gets excited?
- Do the PMs attached to the project have a basic understanding of how software is built and the systems involved?
- Does their management understand the actual processes being interacted with? (Major red flag! If their management / leaders say things in meetings that demonstrate a basic lack of understanding in what their own people do, run)