32

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.

Improve this question
3
  • 2
    possible duplicate of Prototyping vs. Clean Code at the early stages. See also: Develop fast and buggy, then correct errors or be slow, careful for each line of code?
    – gnat
    Dec 11, 2013 at 8:35
  • 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, 2013 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, 2013 at 19:56

7 Answers 7

Reset to default
41

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.

Improve this answer
4
  • 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, 2013 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, 2013 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, 2013 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, 2016 at 13:29
14

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.

Improve this answer
2
  • 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, 2013 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, 2013 at 6:50
10

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.

Improve this answer
5
  • If it's the User Interface that's a problem, there's also ux.stackexchange.com
    – Rob Church
    Dec 11, 2013 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, 2013 at 15:29
  • 2
    Advice can be copyrighted? Surely author would use it as a tutorial, not copy/paste?
    – grizwako
    Dec 12, 2013 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, 2013 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, 2013 at 15:58
2

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.
Improve this answer
2

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.

Improve this answer
1

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.

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

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.

Improve this answer

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