Development life-cycle for making an application?

Question

I have an idea that I want to make into an application (I have a C/C++, C#, and Java programming background so I will be developing in QT Creator for cross-compilation's sake). So now I am asking you senior developers, what should I do next? I know that all good programs come from an idea. Then what should I do? Prototype the UI? Then develop the code? Is there like a circle of the development of an application?
I DO NOT MEAN FOR THIS QUESTION TO BE SUBJECTIVE OR ARGUMENTATIVE

Answer 1

Ok, from a seasoned developer's perspective, most companies I've worked for follow at least a somewhat process-driven approach. Open source projects I've seen can vary widely, from ad-hoc to extremely process-driven. In general though, at least in the corporate world, even on smallish projects, something like the following approaches has worked well for me and the teams I've worked with. Of course, there are many variations, using different paradigms, but in general, these are the types of steps I see across most paradigms (and I'm sure I've left some nitty-gritty steps out):

• First off, have a good handle on your requirements. If your users aren't sure themselves exactly what they want, then @Michael Herold's approach of starting with a UI prototype is definitely one good suggestion. You may also want to go with some type of iterative approach, like Agile/Scrum.
• Next, define some type of high-level architecture that should be flexible enough to achieve your goal. Will your app be client-server? Will it need a database? Multiple threads? Multiple processes? If either of those was "yes", how will those threads/processes communicate. Draw up a block diagram after answering the above questions.
• If your project is of medium size or larger, you may also want to draw some class or UML-type diagrams. Think about what kind of classes you'll need and their relationships.
• If you want to try the Test Driven Development approach, now might be a good time to turn your requirements into unit tests.
• Once you've got a good idea of WHAT you're trying to solve, and HOW you are going to approach solving it, you can finally start coding up a solution.

Some approaches are iterative, such as Incremental Development or Agile/Scrum. In Agile/Scrum, your iterations will be very quick, like every few weeks go through a complete cycle. In Incremental Development, the cycle is typically longer: months or even years. In both Scrum and in Incremental Development, the main thing to keep in mind is that at the end of each iteration, you want to have a usable piece of software (even if it doesn't do much). This helps keep real or potential customers, and even developers, interested.

Whatever your approach, the earlier and more often you can involve your users (or prospective users), either via looking at UI prototypes, or via Usability Testing, the better.

Answer 2

I would say that it depends on what the main portion of the application will be. Will the majority of the work come from designing the user interface (i.e. is that where the "wow factor" comes from?) or is it going to be mostly data manipulation or some other "heavy lifting" (i.e. these are my results in a simple user interface)?

If the application is meant to "wow" people, prototyping the user interface and getting opinions on it goes a long way. This can be done before starting on the code, then incremental updates can be applied as you receive feedback. While you are asking for feedback, you can start working on coding the rest of the application, so each piece is moving along without waiting for one or the other.

The nice thing is that if done correctly, these two things should be entirely (or almost entirely) decoupled and independent of each other.

One last note: by prototyping your user interface, it might help solidify your idea in your head, which will ease designing the code behind the user interface. Different methods work for different people, but in my experience, prototyping the interface is very useful.

Answer 3

Crack on with it. Just get stuck in.

Try to design things to be flexible so you can easily refactor things when you realise you've taken the wrong path. Keep your UI, business logic and data tiers separated so you can easily rework the UI etc later when you understand exactly what it has to do.

It's always hard to know where to start, so the best advice I can give is to just think it all through, pick a bit, and get to work. Expect that you will have to refactor or even rewrite some bits - don't be afraid of this, it's normal. But you could sit there forever looping trying to decide which bit to do first and never even get started. It doesn't really matter which bit you do first, as long as you have an overall plan in mind so that the bits you implement all fit together coherently at the end.

(I'm not suggesting you go off and make a big mess without desiging or prototyping anything first. It's just that one of the most difficult parts of developing a new application is deciding where to start. At some point, you just have to take the plunge and start swimming)