Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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
add comment

closed as too broad by GlenH7, MichaelT, Glenn Nelson, thorsten müller, Dynamic Dec 20 '13 at 19:40

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

7 Answers

up vote 40 down vote accepted

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.

share|improve this answer
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 Dec 11 '13 at 22:05
add comment

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.

share|improve this answer
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
add comment

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.

share|improve this answer
    
If it's the User Interface that's a problem, there's also ux.stackexchange.com –  pink-diamond-square 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? –  GrizzLy Dec 12 '13 at 12:24
    
@smcg: the topic was discussed here: meta.stackoverflow.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
add comment

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.

share|improve this answer
    
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
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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