Prototypes are a good idea. They're invaluable regardless of the methodology you subscribe to; waterfall, agile, or anything in between. Especially if you have external people/non-engineers/"customers" or aren't 100% sure of what you're doing.
Every time I start new projects/jobs I like to try out new things. We experimented with a few different processes and tools (trello, hansoft, post-it-notes) before settling where we are now (jira).
I've not had much need for UML. I think Visual Studio (and probably other tools) can generate interfaces from UML diagrams and that definitely appeals to me. But more often than not the requirements (business/technical/other) are too unclear to invest in relatively heavy up-front planning like that. Was useful on some projects using waterfall, though. I'd only recommend it if you're extremely comfortable playing architect and doing up-front design in the problem space.
That said, I still do lots of planning/design/problem solving with pen and paper or whiteboard with others. It's often a first step for me to quickly think "out loud" to myself before moving to a "real" tool.
Honestly, I've worked on enough small/medium/large projects at enough small/medium/large companies that I don't think it really matters what you use. Everyone just needs to agree on what to use, and then actually do it. You're going to under-estimate how hard it is and things probably won't go "according to plan". If there were any silver bullets everyone would do the same thing. If you're by yourself (or just a couple of people), pick whatever is fun/easy/low-overhead. If it's not working out, learn from the experience and try something else. The goal is to make things, not make how to make things. ;)
This is a phenomenal answer, thanks for writing out!
Interesting perspective about UML. My only exposure was at my first paid development gig, where it was...valued quite highly, and I'm not convinced it was always a good use of our time. I see the merit, but will probably steer clear at least for personal projects.
That's a great point about consistency being more important than the specifics. Some good food for thought here, much appreciated.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Prototypes are a good idea. They're invaluable regardless of the methodology you subscribe to; waterfall, agile, or anything in between. Especially if you have external people/non-engineers/"customers" or aren't 100% sure of what you're doing.
Every time I start new projects/jobs I like to try out new things. We experimented with a few different processes and tools (trello, hansoft, post-it-notes) before settling where we are now (jira).
I've not had much need for UML. I think Visual Studio (and probably other tools) can generate interfaces from UML diagrams and that definitely appeals to me. But more often than not the requirements (business/technical/other) are too unclear to invest in relatively heavy up-front planning like that. Was useful on some projects using waterfall, though. I'd only recommend it if you're extremely comfortable playing architect and doing up-front design in the problem space.
That said, I still do lots of planning/design/problem solving with pen and paper or whiteboard with others. It's often a first step for me to quickly think "out loud" to myself before moving to a "real" tool.
Honestly, I've worked on enough small/medium/large projects at enough small/medium/large companies that I don't think it really matters what you use. Everyone just needs to agree on what to use, and then actually do it. You're going to under-estimate how hard it is and things probably won't go "according to plan". If there were any silver bullets everyone would do the same thing. If you're by yourself (or just a couple of people), pick whatever is fun/easy/low-overhead. If it's not working out, learn from the experience and try something else. The goal is to make things, not make how to make things. ;)
This is a phenomenal answer, thanks for writing out!
Interesting perspective about UML. My only exposure was at my first paid development gig, where it was...valued quite highly, and I'm not convinced it was always a good use of our time. I see the merit, but will probably steer clear at least for personal projects.
That's a great point about consistency being more important than the specifics. Some good food for thought here, much appreciated.