4 ms·

You get those 73 engineers in a room, then what? What do they write? You get 15 engineers, 3 DBAs, 5 sys admins + their managers. While that's spinning up, you

You get those 73 engineers in a room, then what? What do they write? You get 15 engineers, 3 DBAs, 5 sys admins + their managers. While that's spinning up, you get a bunch of business analyists to write the requirements. A first version gets written, it doesn't do what people want and the data it works from is really crappy, so you have to write a bunch of custom edge logic to deal with the crappy data. Repeat several times, including massive changes in scope. Like is there bloat on these projects? 100%, and a lot of it, but saying "just get 73 solid engineers in a room" doesn't really get you very far when the requirements are really really unknown.

throwaway3699 6y ago
Requirements gathering is part of the job. Maybe more of a PM role but still something we all should be able to tackle.
raverbashing 6y ago
Ideally the requirements gathering wouldn't be a pile of tick boxes. Get them to sit next to the users (especially UI/UX) and see how the process happen. Ask questions. See how data entry people work. (Ideally. In the real world it will be a very thorny and boring process)
- JamesSwift 6y ago
  Yes, and in the process of that discovery it turns out the "process" is 100 different processes for 100 different people. One person performs data entry by faxing a handwritten list of excel data. One person just tells the current DBA what to put into the DB. One person uses a homegrown webapp that some intern built to automate some of their process. "This is asinine!" you say. "Just make sure you dont break our existing workflow" they reply.