How much design to do first?

Question

I have never worked with a professional software development team. As such, analyzing and thinking about each and every aspect of my software does not come naturally to me.

Whenever I strike an idea that excites me I just start a new project in my IDE (after finishing the previous one) and I start designing the interface—which means to me as placing menubars, buttons and other components at their appropriate places—and start coding for them. Recently I started a chess game in Java and I followed that pattern: first programmed the black-white grid, then registered a mouse listener etc. without thinking about warriors/objects of chess game.

One thing that annoys me is that I have never been able to completely use object-oriented features of object-oriented programming, though I understand it. I have the habit of taking on things when it comes. This could be the reason of the poor design I end up with.

I complete all the projects that I start, but since they are personal projects I have never felt the need to refactor the code. But I know that if I am asked to modify any function of my program I could be in a mess because they are not properly designed (though they work as asked).

What is the correct/better way to start to design software that is somewhat complicated like a chess game?

Answer 1

So you are always starting your developments first by writing the user interface ? I would say that this way of doing is generally associated with "prototype" development in professional environments, but then again not necessarily. In small companies writing "small" applications and starting with the UI happens very often (also it happens even more often that the "small" application you started grows and grows and grows and becomes a monster application requiring refactoring, additional developers... but I digress)

So it is not necessarily a bad idea, it depends on the size/complexity of the application that is being written and you said it yourself you are writing these programs for yourself. Psychologically, having an UI may also help in that you see your advancements and that gives you motivation. Whereas if you are writing your code-behind and test cases first it may take a dew days before you really start to dwelling into the UI... Unless your mind accepts that test cases are achievements too :)

However, as you said it yourself, doing the UI first without thinking about the backbone of the application will lead you into trouble. It is very tempting to start the "fun" part (I am like you, I like having neat interfaces). But, before that, and even for small programs, just stop for a moment, take a piece of paper and draw some diagrams about how your application works. How your components will reacts to UI events. What are the business (or game!) rules to implement. Prepare a quick to-do list of things to implement and prioritize them by what you think is critical. Also, when programming, resist the urge to implement not critical features/options that will inevitably come to your mind, note them down and take a look at them after cooling down.

You should strive to achieve maximum separation of UI and business/game logic. Ideally, your game code should work whether you have a command-line game (for example: "play e2e4"), a simple 2d UI, or a full-fledged 3d UI driven by the latest version of DirectX. Complete separation is not an easy job and it is where knowledge of Object-Oriented and event-driven programming will be most useful.

Now, the good thing is that you both love programming and writing programs, and you are just a little over-enthusiastic... No scratch that. You are enthusiastic and that is a good thing.

On the refactoring subject, you may not feel the need for it, but maybe it is because you know that your code is a mess and that it would take forever to change things. However, if you organize your ideas a little bit before starting, you should have less code to refactor (but there will (should?) always be a little voice in your head that says "this could work better if..."). Check out other questions on this website on the subject of refactoring, other people have covered much better than I could do it.

Finally, if you feel you are not writing proper OO code take a look some books you could read in order to improve on that, for example: https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read

Answer 2

"What is the correct/better way to start to design software that is somewhat complicated like a chess game"

I think you want to avoid complexity and strive for simplicity when designing software artifacts. One book I can highly recommend to you on the subject is Eric Evan's Domain Driven Design, which outlines various strategies for designing software with a strong bias on having a discrete domain layer in place for your software projects.

"I know that if I am asked to modify any function of my program I could be in a mess because they are not properly designed (though they work as asked)."

It's easy to be wise with hindsight and point out the failings of an application once it's in a state of readiness, but you need to recognize that the whole process of good software development is a ongoing process and new strategies/technologies come out nearly every year. I may not be interpreting what your saying here, but it sounds like you lack confidence a little. Do people give you feedback on your code? One way to start the ball rolling is to do code reviews or even some pair programming. Eventually, you'll build up your confidence and be able to tackle a software project without too much worry. Typically, I never think of a software project as "finished" as such. It can always be improved and tidied up in different ways. Be a critic of your work, when you've written a class/method think about how it could be improved, imagine that code was submitted to you by another developer for review. What advice would you give him/her to improve it?

With regards to reading, I'd certainly read Domain Driven Design and I'd have a look at Code Complete. You should also have The Pragmatic Programmer somewhere near the top of your reading list. You can do all the reading in the world, but to get confidence and improve, you need to actively develop software projects, being a critic of your own work and also getting feedback from other developers.

Answer 3

Whenever I strike an idea that excites me I just start a new project in my IDE .That.. and I start designing the interface—which means to me as placing menubars ... Recently I started a chess game in Java and I followed that pattern: first programmed the black-white grid, then registered a mouse listener etc. without thinking about warriors/objects of chess game.

Nothing wrong with that, we have to start somewhere.

One thing that annoys me is that I have never been able to completely use object-oriented features of object-oriented programming, though I understand it. I have the habit of taking on things when it comes. This could be the reason of the poor design I end up with.

I think your poor designs are a result of a lack of experience and knowledge. You know that your designs are not good because they are hard to modify, but you don't know how to make them better. The fun thing about software is that it is infinitely changeable; you can keep adding code bit by bit, and improving the design as you go. But you still have to know what changes would improve the design. I recommend that you read Martin Fowler's Refactoring, and Design Patterns by Gemma et. al. However, keep in mind that the idea is not to choose design patterns before coding, but to recognize the applicable design patterns as you code.

Answer 4

A big part of design is functionality. Don't fragment it and constrain it into arts only. So as you build the architecture, intertwine with it and visualize a design that unifies not only makes it prettier but also evermore so functional.

Examples of this are: Leonardo Da Vinci's work, Apple Design etc.

Also wikipedia has a good entry about "Form over Function" : http://en.wikipedia.org/wiki/Form_follows_function

I adopt a similar view although function is rigid enough where you can customize and beautify the product without necessarily hindering it. Our human sensibilities are still there no matter how much time we try to be functional and objective.

A good example too is the iMac with it's handle on top. Nobody moved their iMac around, but it allowed a subconscious message that emanated, "Human Control/Handling" over a machine. Small touch but it did move a lot of sales!