Skip to main content


reshared this

in reply to Hank G ☑️

Where I worked before, we absolutely relied upon the requirements documents. I don't see how one can "develop" without first doing a systems analysis and developing requirements - that's about 60% of the project right there.
in reply to tomgrzybow

It really depends on what you are building. Usually you have some idea of some approachable first cut MVP with a few features that can be built in a short period of time. That's not really a project wide requirement document. So you build that and then iterate by seeing where your users are going, what is working, what's not etc. Then there are others with hard R requirements. Like I was working on internal an inventory management app that was replacing an old legacy system. There were very specific requirements for what sort of items and actions needed to be tracked and reported and what sort of systems it had to interact with. That needed a lot more pre-development requirement development and even some mockups because we weren't sure what UI/UX idioms users were going to find intuitive as we moved from the old clunky system but one they knew like the back of their hand.
in reply to Hank G ☑️

in reply to Hank G ☑️

Yes, I worked in big-pharma research and development. There you have to know precisely what you are doing and why before you do it. The systems are complex, and there is no "trying things out".
in reply to Hank G ☑️

I came to enjoy systems analysis even more than programming.
in reply to Hank G ☑️

I like Agile as a guiding philosophy. The four this over that statements can help organize thoughts and prompt right action. In my experience most software engineering doesn't involve building something new, but rather, making changes to an existing system that hopefully is a net improvement. How does one do that? Lots of reading code, trying it out, thinking about trade-offs, etc, etc.