Making it work V/S Making it work right

Question

I am somehow a bit good at coding algorithms for small projects, but when it comes to make an attempt for some biggies, I make a total hodge-podge and marshmallows of my project's structure. I have studied a lot of books on software engineering and SDLCs where they say that becoming a developer is what every nook and crook can do, but the actual developer is the one who follows a systematic approach to the problem and solve it the way its meant to be.

My code works fine for such jumbled up projects, but it gets too difficult for maintenance and further upgrades.

So, I would like suggestions so as what should be the proper approach to planning the big moves

Answer 1

A slight aside but good design will only see you so far as it's not always possible to know where the project is going months or years in advance. What is the right structure today may not be the right structure in a year when you've been asked to make changes, where your up front design turned out to be non-optimal and so on.

The answer is to refactor as soon as you see a problem - rework your code to remove the mess as soon as it starts getting messy. At any given time the solution should be right (or as close to it as possible) for what you've coded so far.

This takes time obviously but in the long term you'll end up with a solution which will remain usable and maintainable for far longer than if you don't.

Answer 2

It sounds like these are personal projects, so here's what I suggest:

1. Write a one-page (max) description about what this system is supposed to do. No code samples, no screenshots, just a simple textual description that you could read to someone else and give them a high-level overview of what the system does.

2. Write some simple requirements for the system to describe how you will build the system. Include sample inputs and outputs and data for where it's helpful. Screen mockups for where it's helpful. Diagrams of database design, flowcharts, etc..., can be helpful.

3. Break the development down into small milestones that are easily achieveable. For example, instead of something like "Build full GUI", have: "Build main screen", "Add buttons for Add/Update data", "Add functionality for buttons", ...

4. Feel free to revise any of the above parts as development goes and you learn and discover new things. Sometimes a design decision that seems brilliant at the early stage becomes unfeasible once it's time to put it to code, so it's OK to go back and change things.

If this is for personal projects, you don't need to do this very formally, just enough to keep your thoughs organized and clear.

This is what works for me, anyway. ;)