2

I am working on large project solo as a hobby, and I made a mistake in the very beginning: I jumped right into programming without giving a second though to design. Now I am nearly 6 months in and things are starting to fall apart: I cant get anything done, the code is very inconsistant, and the whole thing is a mess. Ive definitely learned the importance of design in software development, but I dont know how one designs software to begin with. Are there any programs that can help with this? Or do I need to sit down with pen and paper for the next few weeks trying to work things out?

  • 2
    rewrite from scratch – ratchet freak May 25 '14 at 21:36
  • 1
    possible duplicate of Techniques to re-factor garbage and maintain sanity? – gnat May 25 '14 at 21:38
  • Definitely a option, but I need to know how to design it correctly this time so this doesnt happen again – cilki May 25 '14 at 21:38
  • 3
    Learn from experience, the next program you write will be better. – Greg Hewgill May 25 '14 at 21:43
  • If you don't want to rewrite, then you have refactoring as a low abstraction level tool, and context mapping as a high abstraction level tool. First you have to make a context map, and a plan about how to change that map. After that you can define issues, milestones, etc... as usual, and you can start with the refactoring. You cannot refactor without tests. If you don't have unit tests, or sometimes even classes, then at first you have to write end to end tests for the entire application or at least integration tests for each module. For that you'll need user story or use cases. Good luck! ;-) – inf3rno May 26 '14 at 3:05
9

Things are falling apart and you are reflecting about it. You try to do it better next time. So the good news is: You are on the right way, and what you experience right now is called learning.

Let me tell you a story. Once ago, I was in a similar situation. There was a piece of code which suddenly became more complex as we (two unexperienced people) were able to handle it. The signs were similar to the ones you see: The code began to become brittle, and fixing one bug introduced two new bugs. In a nutshell, the whole thing started to develop kind of its own, uncontrollable life.

That's when we found out that unit testing can be a great tool. It was years ago before such things started to become mainstream, and it was the single insight that basically saved the project. We started writing test cases methodically, which made sure that we left the code in a better state after the next issue had been fixed. For every issue fixed and for every new feature, we added at least one test case to make sure everything worked and none of the identified and fixed problems do rise again their ugly head - and if so, we would at least be warned immediately.

The book I was reading at that time helped us with that insight. It was Steve Maguire's "Writing Solid Code". Sure, it is a little outdated in the details, but most of the principles in that book are still valid today, and not only for C programmers. The basic message is to do whatever you can do, and to use whatever tool is suitable to make your code rock-solid.

I jumped right into programming without giving a second though to design. [...] I cant get anything done, the code is very inconsistant, and the whole thing is a mess.

The best advice here is probably: Don't be afraid to throw code away and rewrite stuff that isn't working. It will take a little more time today, that's true, but you trade that against much larger benefits in the long run, because you don't have to deal with the mess any longer. Have your unit tests ready to check the expected outcome. Consider using TDD, it may be what you need to get the beast tamed. And last not least, test your error handling.

Ive definitely learned the importance of design in software development, but I dont know how one designs software to begin with.

That's something you should absolutely learn, both in theory and in practice. Try to study up good solutions in other people's code, for example Open Source projects are a very good source. Try to understand what the code does, maybe ask people whenever you don't understand it.

A good pattern and anti-pattern book may help as well (e.g. the GOF stuff), but you should try to apply patterns into practice to make sure you really understand how they work and what they are good for. Try to implement some of your code again with these principles in mind. Develop the ability to see the big picture behind what you are doing. How could you split that big ball of mud into small, re-usable pieces? What patterns can you identify? How to design the interface between these components? Then try it, practice and learn. Talk to people and let them review your stuff.

| improve this answer | |
  • 1
    "Open Source projects are a very good source". Sometimes. I've seen some truly excellent and innovative code in OSS but at the same time, I've seen some really awful architectures that are there because features have just been bolted on ad-infinitum. Patterns & Practicies is definitely worth a read (don't worry if you don't understand all of them to start with, you'll start to see problems where you think "aha!") – Basic Sep 19 '14 at 16:00

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