Hacker News Reader

Comment by MaknMoreGtnLess | Hacker News Reader

Depends on the context and environment.

If I am a cofounder at a startup where the market isn't even defined yet, my priorities are to help discover the market. Then build an MVP off the immediate needs of the beachead market.

If I am an employee at an established company where there's a well defined, effective market, customer team, I work with them to get usecase definitions, then I write BDD/TDD and have rest of my engineering team help implement.

Are you looking for specific help? In that case, do mention the context and environment you operate in

View on HN

> Are you looking for specific help?

No, I am not looking to solve a specific problem. The way I start a project is to draw a very simple(throwable) sketch of what the software design will look like, and then iterate over it as I write the code. Lately I have started slowing down because midway through writing code I start rethinking the design and start over again from scratch. So I was just curious what approach others use and is there a way to avoid the situation that I am in.

What kinds of sketches do you draw?

Try to write pseudocode for the critical parts so you can test your design before you write code.

> What kinds of sketches do you draw?

Sometimes class diagram, sequence diagram, pseudocode, scribbling on piece of paper etc; whatever gets me going quickly.

It sounds that you lean heavily on OOP methods.

I find OOP to be weak in the design stage. It does help later to simplify the code. But, only after you find out where the actual objects are. I prefer ERD for any modeling I might need in the design.

Older methods like structured design and data-structured design offer better guidence in the design stage. Too bad people look down on anything that is not OOP (or the newer hype FP).

The most useful method by far, however, is to recognize the shape of the problem, look for and apply a known solution.

I use ERD as well. I use whatever gets the idea from my head on to a paper quickly.

> midway through writing code I start rethinking the design and start over again from scratch

What's the source of requirements you're building to and who verifies those?

If you're creating requirements out of thin air, just so you can build something (eg: you want to learn something) - your current approach is absolutely ok.

This is for the side project I am working on, so there are no requirements from external parties.

Reply on news.ycombinator.com