I have just started a new project and like all new projects, I start mentally mapping out what tools and objects I will need to get a reliable Alpha up and running.
With great glee I sit down in front of my mac, fire up Xojo and spend the next hour staring at the sidebar wondering if I will need a module or a class to serve the project? Will all of the names and naming conventions I use lead to rampant unreadable spaghetti code. Is this a common thing to do, or am I just mentally challenged? Somebody told me that you need to know what the finish line looks like before you can find the starting line. I am not sure that this is relevant, but it sure sounds impressive.
Nope, I don’t do this. I start with the data structure and the process first. What do my users want to do? In which order? What data does this need?
HTH
Depends what I’m intending to make. If it’s not too complicated, uses parts I’m very familiar with and just mentally I have a sense of what’s needed, then I’ll just start coding it up on the fly.
But if I sense my mental model is too vague about an aspect or I want something robust then it’s some pen on paper time mapping out necessary dependancies and wants and possibilities.
This looks like when a writer want to create a book: it first creates the Table of Contents, add a some text to it (to get a synopsis) and at last, fill the chapters, subs, etc.
Nota: Microsoft Word is champion to create Tabel of Contents: once the book is over: just use the predefined styles into the book and when done, fire the Create the ToC MenuItem ! (and youre done).
Its just fantastic ! Excepted that I never follow the advice given in the first paragraph. ;-
[quote=187827:@Emile Schwarz]This looks like when a writer want to create a book: it first creates the Table of Contents, add a some text to it (to get a synopsis) and at last, fill the chapters, subs, etc.
Nota: Microsoft Word is champion to create Tabel of Contents: once the book is over: just use the predefined styles into the book and when done, fire the Create the ToC MenuItem ! (and youre done).
Its just fantastic ! Excepted that I never follow the advice given in the first paragraph. ;-:)[/quote]
This reminds me of when I first started using VB. I would create all of the menus and a feature list, then figure out how to make all of the features work.
No offence, but that’s exactly the wrong way to write great software. It is quite the same if you would prepare a presentation sitting in front of powerpoint without an idea what to tell.
My Mac is not even close to me when sitting at my desk, just equipped with a pencil and a paper block. First I look at the steps and processes from the users’ perspective . Which information is asked in which meaningful order? Shall I use an extra window? Does a Dashboard make sense? What is the main purpose of the software? Are there ways to prevent unneeded Inputs because the information is already in the data? (e.g. why not dropping an date input field when it is always today?).
When your processes are sketched out you will hava a foundation for your required data. The next question is how to normalize it. Where to store it? This brings you to your objects. Most objects I use just do reflect a database structure: An Object for Customers with all its properties and methods is similar to a recordset of a table named Customer in a database.
And the last step brings everything together in a more readable form. Here is where I turn on my Mac and start writing down or sketching a mind-map or creating a PAP (=Programmablaufplan - do not have an english word for this) . It’s secondary which software you’re using. Some use Word, others Photoshop or Vectorbased programs. I am using Diagrammix from the App Store.
This is the time to evaluate the neccessary time and budget for each step, module or component. Here I decide the question: Shall I do this by myself or shall I hire an external devloper or buy a component. This is the foundation from where I start negotiations with the customer… and so on…
… and couple of years ago this was the point where I decided which language to use… since 2010 the choice falls to Xojo 
The better you prepare these steps, the better you can respond to customers’ needs and questions. It’s easier to document and calculate
I use something very similar to Tomas’s approach, however, I would not know the entire end project before I started. I would know what the minimal functionality is that would provide a benefit to the end user. I then work toward that. I will certainly have ideas floating in my head about where it may go, but I get the minimal possible work done then start getting user feedback to help shape the future.
software is never finished… especially business software… it is always an evolutionary process…
The ideal is something rather different from reality. Reality for each developer is personal therefore three developers will have four or more opinions on what is best to do. Each situation will need the process you use regularly to change sometimes slightly and other times drastically, so it is personal comfort and experience that sets the process. The questioning of your sanity is best left out of this equation since the process is truly down to what you find delivers… for you the best possible result. Having an open attitude towards change that strengthens your development efforts when introducing different techniques over time and projects will generally give opportunity to keep what works for you and drop that which does not. The ideal class or structure or object is fleeting… no sooner than you get it to work and either an end user or a project sponsor will ask for something that makes the ideal no longer valid… or you have gained in experience and see the folly in the design of the class or structure or object… take comfort in the fact that software building is an intellectual challenge you embark on to improve yourself with… we are all on a journey of discovery and it is software building that has captivated our interest long enough to have some products in the wake of our mental journey of discovery.