Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just developed my first non-trivial android app. It was a complete nightmare. I came up with an idea, build the app, changed my idea, and implemented a lot of input from others on new features. All in all my app took 10 times longer than I think that it should have, it is almost impossible to look the source code and tell what's going on with the classes, and may or may not have unused methods that I'll never be able to find...

So I would like an opinion from those of you with experience on how to plan out my designs for the future. I created a flow chart (pencil drawn) of a plan:

flow chart of plan

I would like constructive criticism.

share|improve this question
up vote 4 down vote accepted

The biggest step you're missing is a refactor step. As soon as you don't use a method anymore, delete it. As soon as you can't follow the flow of a class, refactor it. The first time you have to figure out again why you did something a certain way, document it. Always be on the lookout for opportunities to improve the code, and take them before it gets out of hand. It will save you time in the long run.

share|improve this answer
I see. How often should i go back and refactor and where does this fit into the flow chart? obviously when i first design the class it makes sense, however, a week later that isn't always true. – adam kim Nov 26 '12 at 18:52
It goes in there with "test." You do it as early and often as necessary. – Karl Bielefeldt Nov 26 '12 at 19:43

What you have experienced is quite normal. The estimations when you are a junior developer (based on your text I assume this) differs largely from a good and experienced senior developer. A senior developer will find pitfalls already in architecture phase of a project and takes this into accountance in his estimation.

Next point you mentioned is that a project with a new technology will take more time than a project where there technology is already known.

Next is refactoring. As Karl already mentioned refactoring is needed. For your question about how often must be refactored: Refactor the application when it is needed (the code smells). I personally refactor about one third (more or less) of the time. And I do this immediately if it is needed.

I hope that this insights help you (at least with your next project).

share|improve this answer
Thanks it sure does. I think there really wasnt any way to prevent this my first time since, as you predicted, i wasnt good enough at programming to even know the difference from good and bad design. I think taking a waterfall design approach for my next project will really help me from wondering around in circles. Its funny but it seems what i did was almost like an agile approach of build halfway and then tear it apart if they dont like it. – adam kim Nov 26 '12 at 19:42
I think here is a misunderstanding. Use agile development if you like it. To plan a development project using a waterfall is much more difficult. Try using an agile method and go further step by step during development. After a while it will be continuous. – Uwe Plonus Nov 26 '12 at 20:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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