I'm working on my own application and I'm stuck. I have to implement a feature but I can't find a good approach to implement this feature. I was thinking about it for a couple of days, and no good thoughts came. Searching the Internet didn't give me any inspiration.

I need to move on, but I want to know, what's the best:

  • Think more, wait more, and keep on searching for the best approach
  • Stop wasting time and start with poor design, covering everything with tests

What do you think? As I said before, I'm working on my own application. I don't have any deadlines, but I also want to finish coding the app asap.

  • 2
  • 12
    @gnat: These other questions deal with situations where the askers already know how to implement some features cleanly, but may want to sacrifice a good design for beeing "quick and dirty". This question, however, describes a different situation, it is about problem solving in general when you don't find a good point to start at all, so it is IMHO no duplicate. – Doc Brown Dec 11 '13 at 8:57
  • note: if the app is a success you'll never "finish coding it" and features will get redesigned anyway. So I would go with implementing it the best way I can now. – ren Dec 11 '13 at 19:56

Apart from talking to people about it (question suggests you don't have colleagues on the project), I often find it a good approach to focus on the things I can do.

Usually there is some part of the code that I know I must write anyhow. The stuff I don't know how to write yet, is then replaced by stubs that either return dummy results, or use an approximation that is good enough to test the rest.

This keeps you productive. And by the time you need to implement the missing piece, you have the interface. And you have written a lot of code surrounding the problem, in the same problem domain, which usually helps me to generate ideas: you know more exactly what you are required to output, and what other inputs are available if it helps to solve the problem. Also, often the conclusion is that the missing piece does not need to be as all-encompassing as initially thought.

  • 6
    The downside of writing the riskiest, least understood code last is that you may find out that it is not possible to solve the problem, or only possible to solve it with substantial changes to the program's architecture, leading to a lot of wasted effort. – Rich Smith Dec 11 '13 at 16:15
  • 1
    The other downside of this approach is sometimes leads you to, "I can solve problem X. All that's left is to do Y." when in reality, Y isn't feasible and the real solution is Z. – Brian Dec 11 '13 at 17:10
  • @RichSmith, Brian: It happens, although rarely if you ask me. It then can provide you to a better understanding of why the missing part is so hard, which improves your estimates. And I would not suggest to put in weeks of work based on a speculative and arbitrary division of responsibilities. – jdv-Jan de Vaan Dec 11 '13 at 22:05
  • it's arguable whether or not those are downsides though. would your time have been better spent not exploring the issue at all? or by you sitting around guessing what would work? I think it's good practice to write quick prototypes, try stuff and to fail fast. it's the only way to know for sure and to gain experience for future similar situations – sara Apr 21 '16 at 13:29

If searching fails, you could always implement using the first (not necessarily the best) idea you got, and then refactor it later when you find the right approach.

This is the right approach, since even if you find something that looks like a good idea, it may turn out to be bad later on. Or it may be good at that time, but later you find something much better. Then you'll still have to refactor.

When doing this, make sure to design and implement in such way that it is easy to refactor. If you do it properly, you'll have to change only the problematic part, and not start from start.

  • 1
    It seems to be assumed in this post, but I'd like to add that it is very important that you write your code in a fashion that it is easy to re-factor. – c_maker Dec 11 '13 at 15:10
  • @c_maker Yes, of course. Otherwise, it makes no sense to rewrite everything later from scratch. I'll add it to the answer. thanks – BЈовић Dec 12 '13 at 6:50

What about asking another person? For example, you could describe your problem here, or, if it is more an implementation issue, on stackoverflow.com, and ask for ideas. Sometimes it will already help you if you start writing down the problem, even if you don't get good answers.

  • If it's the User Interface that's a problem, there's also ux.stackexchange.com – Rob Church Dec 11 '13 at 14:48
  • if you ask on SO then answers are going to be copyrighted under Creative Commons, and depending on the project, that code could be unusable. – smcg Dec 11 '13 at 15:29
  • 2
    Advice can be copyrighted? Surely author would use it as a tutorial, not copy/paste? – grizwako Dec 12 '13 at 12:24
  • @smcg: the topic was discussed here: meta.stackexchange.com/questions/12527/… - But honestly, if that's really becoming an issue, I think one can circumvent this by the way GrizzLy suggested. – Doc Brown Dec 12 '13 at 15:04
  • @DocBrown IANAL so I cannot say for sure if that would hold up, but sometimes it's good to err on the side of caution. – smcg Dec 12 '13 at 15:58

A few ideas:

  • Brainstorm
    Write every stupid idea you have down (on paper or whiteboard). Cross the ones off that you're sure won't work. Keep writing. Include solutions to potentially related real-world problems. E.g., does mixing paint, or putting a nail in the wall, or changing your oil solve a real-world simile?
  • Ask for help
    Google it, ask here, ask your geek friends, etc.
  • Solve a related problem
    You can't solve the problem, but can you solve a much simpler one? Or an equally complex, related one? Do that. Then make small, individual changes to bring your solution closer to the desired solution.
  • Just start writing from the outside in
    Regardless of whether your interface is a web service, web page, native form, camera, keyboard, monitor, or whatever, there's an interface. Write a few lines of code/pseudocode to make the interface work. Use magic methods that don't exist yet. Recursively do the same for each nonexistent magical method. Optimize later.

There's nothing wrong with going with the bad solution. Often times you just don't know enough about the problem domain at that point in time. Going with a bad solution let's you move on and learn more about the problem. Then you can still go back and refactor your first solution.


I always try and look at it from an end user perspective. Its very easy to think of a "cool" idea as a developer that you can spend ages working on that actually adds very little to your app.

Ideally you want to map out all the features in your app and prioritize them according to the benefit to the end user, personally I use MOSCoW, although as long as you keep your method of prioritization the same throughout it can be as simple as a 1 - 5.

After which if you still find that this feature is an essential part of your app then as people have already said, ask! I don't think i've ever encountered a problem that eventually hasn't been solved either by a colleague or those nice people over on Stackoverflow.

  • Cool, because I'm from Moscow :) – user21974 Dec 11 '13 at 16:31
  • There you go its a sign! – Mrk Fldig Dec 11 '13 at 20:47

My opinion is: never write code that just works! It should be very difficult to refactor in the future.

It's a really common approach for developers (and of course PMs or bosses). I heard a lot of time "just make it working" or "I'll fix later" (later when??? never!) but, I think that quality isn't something you cannot obtain in the middle of the project.

My suggestion is, stop thinking to your problem for a while.... do something other, and, sometime, the solutions just comes out himself.

Btw, asking to a colleague is absolutely a great way to solve your trouble.
