I know a lot about programming syntactically. What I am unsure is about how should I go to build a software from scratch. How should be the objects be designed and how should they interact with each other.

To learn how good softwares are written I have tried to read code of some good open source softwares but could not get a slightes of idea, how they are designed as there is no availble documentation available regarding the code.

I want to become a more skilled programmer but I could not go any further, I am well versed in programming but now i am stuck as I have no way to go forward.

Please guide about how should I learn the software design and what should be next to improve the skills.

P.S : I am a hobbiest programmer, i have never worked in a software house neither am i looking forward to it.

  • Look for "modularity" and "dependency injection". Apr 8, 2013 at 19:44
  • 3
    Look for "Gang of Four" and/or software patterns and practices.
    – Jon Raynor
    Apr 8, 2013 at 20:09
  • 4
    Just like any other skill: practice. Design (and write) little programs until the design is good, then get a little bigger; repeat.
    – Telastyn
    Apr 8, 2013 at 21:27
  • 1
    @Jean-PhilippeLeclerc It might be too soon for the OP to read about dependency injection. It would confuse him rather than help him at this time. Apr 8, 2013 at 23:26
  • 1
    @Jean-PhilippeLeclerc It's a concept I perfectly understand now, but in the beginning I did not understand how it could be beneficial. It's like everything in programming, once you understand it, it becomes very simple. Apr 9, 2013 at 2:51

2 Answers 2


Start building small "completable" projects from scratch using your existing knowledge on your own as side "projects" ..just make them up. Then refine / refactor the design by identifying and implementing Patterns / "good principles" you've learned from your reading / learning. Once the project has been completed and "refactored thuroughly", Do it again...

There are definitely some architectural "starting points" like keeping various "code layers" separate (DB access layer, Biz Logic layer, etc..). As well as trying to identify where "Interfaces" can be used so you can "extract" their "implementations" and begin introducing some kind of Dependency Injection framework... But that can be done during later passes of your "refactoring" efforts (if that's a path you even want to go down).

I would say there's no "silver bullet" or "this is how you do it" because projects vary so greatly. You can watch pod casts and read books, which all help becoming an expert, but until you are able to implement what you've learned, there's still a pretty large gap, and the only way to implement what you've learned is to either do it and learn from your own mistakes, or find a good mentor who can teach you what they've learned from their mistakes..

"Just having the map doesn't get you to your destination"


You are basically asking how to design programs. It turns out there is a book which teaches you that, and it is called … How to Design Programs (aka HtDP). It teaches you, well, how to design programs. And it does this by giving you recipes to follow for how to analyze problems, solve them, transform them into algorithms and further into working programs.

Note that "recipe" is basically another word for "program", so in other words, the book teaches you programs for humans to run in their heads in order to generate programs to be executed by computers. How cool is that? :-)

The authors are currently working on a draft for a second edition of HtDP, which you might want to read instead of the first edition. The material about imperative programming has been removed, and is going to be covered in the as-of-yet unwritten second volume How to Design Components, but you can read those missing chapters from the first edition.

Note that HtDP assumes no programming knowledge and is targeted at high school students. But don't let that stop you: it just means that you'll probably be able to finish some early chapters faster, but I don't think you will be bored.

Concrete Abstractions is also a good read along similar veins. Like HtDP, it doesn't assume any programming knowledge.

Another book that you might hear mentioned is Structure and Interpretation of Computer Programs aka SICP. It is one of the greatest programming books ever written, and again, it doesn't assume any programming knowledge.

It is, however, geared to complete newbies who study at MIT. And so, while it does not assume any programming knowledge, it does assume quite a bit of domain knowledge, e.g. in the fields of electrical engineering, physics and math. Note: these have nothing to do with the concepts being taught, they are just needed to understand the exercises and examples. So, it might be better to read HtDP or Concrete Abstractions first, and then read SICP.

Not the answer you're looking for? Browse other questions tagged or ask your own question.