When you start thinking about a programming project, what do you do first?

To start thinking about architecture or design, I tend to write hypothetical pieces of code that I would like to "just work" to solve the underlying problem of the application.

For example, when designing my database, I usually try to think of some of the examples that I expect to write, rather than thinking abstractly about data objects and relationships.

This approach helps me (personally) to avoid going too far with the abstraction for the first pass. You can call it Nice Code First. It bears similarities to TDD, except that you first target expressive, concise code, and then architecture and abstraction to support it.

It is my personal opinion that expressive, straightforward code is much more desirable in the long run than clunky, thoroughly tested code. Of course, they are not mutually exclusive. Just don't let the pursuit of beautiful "architecture" lead to clunky client code in your business logic.

I almost always start by drawing a rough model of an object to give me a visual idea of ​​the structure of the system. then build from there.

In a programming project I'm going to assume "for the client" and not a hobby / personal project.

First, I start with what the client described to me, at a high level, what they want. I'm looking for things like "I want a ticketing system that has multiple departments and allows for email replies / updates." Something quick and easy.

From there, I start the first draft of the specification document. I start to ask clients questions to help improve the original drawing and move to a more granular level until the system is finally fully defined. And completely, I mean the client can't give me more information about what they want.

For a personal or hobby project, I usually spend a few days in my head designing some basic database schemas on paper or in my modeling program. I like to sleep on it a few nights to see if it’s something that I’ll keep curious about and not give it up until it’s complete. Once I have determined that this is what I will see, I will proceed by writing my own specification and going from there.

I sit down and start coding ... then I delete all project files and go to the board and start displaying objects and relationships.

I keep a notebook in which I write down all the ideas I have. I usually write a page or two of dense notes about a project / product / etc and then leave it alone because I don't have time to do anything about it. When it's time to design, I'll reread my notes and try to create a class diagram in UML. This usually fails, resulting in more pages of notes that improve the idea, solve weird edge cases and undefined things, etc. Rinse and repeat. Once I have a class diagram that documents all of the major players, I start coding.

• Collect the requisites
• Prioritization
• Effort assessment
• Get started
• Tracking and measuring progress.

I write down a list of functions, then go to it with a little detail, then start writing some objects and how they will interact with each other, like a half-resource DFD .. all my drawings are a mess!

I grab a pad and a pen and start drawing notes and flow diagrams, nothing out of the ordinary, just rendering a conceptual model from which I try to break down every part in simpler and simpler tasks.

As soon as I can't simplify things any further, I start writing, losing pseudocode, and deleting the database schema. Only after that do I start coding the sample / test code.

An attempt to analyze the business area. those. the structure of the busienss problem the application is trying to solve. What entities need to be manipulated / managed, are they mutable / immutable? What processes (from a business point of view) does the application need to execute? Which object does each process require, and for each, what does the process do with this object? etc.

I would start by documenting the vision , a short document describing the project, the business around it, and the criteria for success.

This helps prioritize features and gives the same direction to everyone working on a project.