This is fine for a sketch, a prototype, or an exploration. If you do this to produce production, critical path code, on a professional team with others you're selfish:
- The team, not only you, maintains this work that they have no agency over.
- You skipped feedback loops, and ignored the expertise of others.
- You've removed information sharing and visibility as you go into your cave and come back out with a solution.
> I feel that you can't work the way I work, unless you are highly experienced (I've been at it over 30 years). I make big decisions, on the fly, and I need to have a really clear idea of the ramifications of these decisions. Often, the devil is in the details.
Yes, the devil is in the details. Get some feedback from other people and stop designing by mistakes I happened to notice and catch. The ones you didn't notice? They're bugs your teammates fix.
Thanks for the insult. I appreciate the feedback.
I'll do me. You do you.
Have a nice day.
I call it "concrete galoshes." The structure can become more important than the project.
That said, not having a structure can be absolutely deadly. It's not for the faint of heart.
I seldom write down a detailed project plan (I write about that here[1]. Feel free to not read it, as well). Instead, my projects start with what I call a "napkin sketch," and evolve, as they progress. The results can be amazing, but I also end up backtracking a lot, and tossing out a lot of code.
I feel that you can't work the way I work, unless you are highly experienced (I've been at it over 30 years). I make big decisions, on the fly, and I need to have a really clear idea of the ramifications of these decisions. Often, the devil is in the details. It's quite possible to decide to do something one way, and get there, and then realize that a corner case makes the design unusable, and/or downright dangerous.
I'm not a fan of "design by buzzword." Modern techniques are often marvelous, but they can be unsuitable for some applications. Having a toolbox available, that includes a wide range of options, is invaluable.
I am a fan of early, high-quality usable product. One of my techniques, is to leverage Apple’s TestFlight beta service, as early as possible. This allows non-tech stakeholders to have meaningful say in the project. Screenshots and interaction diagrams are fairly useless. They take a lot of time (and expense) to create, and no one reads them. They also tend to add unproductive rigidity to the project.
[0] https://littlegreenviper.com/miscellany/concrete-galoshes/
[1] https://littlegreenviper.com/miscellany/evolutionary-design-...