Starting to develop a new piece of functionality - easy or difficult stuff first?

Question

I'm starting a new 'sprint' to develop some functionality. I need to extend some stuff within two separate components of our entire codebase.

Both are equal in difficulty in terms of the actual development required, but I am familiar with one of the components and not the other.

Now before I dive in and get started, which should I work on first? I may start the more difficult one, to get it out of the way and that way I'll know that it will get easier approaching the deadline. I'm very tempted to just get stuck in with the easier one though!

What's your approach to this? Easy or difficult tasks first?

Answer 1

You should start with the most important one.

If they are both equally important and absolutely have to be finished this sprint, I would advise to start with the hardest one.

Answer 2

Will one compliment the other? Will there be code that you can reuse from one module to the other? Are there things you can learn from one that can aid you in doing the other?

These questions could help you in deciding what to do first.

Answer 3

Divide the hard task into smaller tasks, etc.. I don't like to have one small task beside a ONE HARD HUGE TASK. I mean, start by cracking the hard task, instead of implementing it directly. So I would choose starting with the hard one first.

Answer 4

I'd start with the one you're most familiar with so that you can show some progress early and leave yourself lots of time to work on the one that you're less sure of. Only trick is to avoid gold plating the first bit too much to stay in your comfort zone a little longer...

Answer 5

'sprint' ... seems like agile

What the client wants (highest biz value, importance) defines what to to do first,the client here can be you.

Start with the task that will lead to maybe very basic, but working functionality is ready... then enhance it iteratively.

and you should have a near and fixed deadline‍‍(s) , so you select some tasks that fits into it (split tasks down to small units).

Answer 6

Start always with the part that is most likely to give you insights about what doesn't work or is missing in your approach - and achieve this quickly. The goal is to reduce uncertainty about your development schedule as soon as possible.

If the easy part can be done very quickly, it might be preferable because it reduces uncertainty sooner, if not as much as the hard part. But in your case the difference seems to be entirely in your uncertainty about these two components - in that case tackling the unfamiliar one first is definitely a good idea. In doing so, you may run into problems - and those will be much easier to handle and less costly now than right before the deadline.

Answer 7

I would start with test first. this would help me to clarify the needs and to write down the requirements.

Then I would implement the easy stuff. Just for keeping a high motivation level.

Finally the hard stuff, when deeply in the zone, when ideas flow seamlessly.

Of course after having written the tests, easy and hard stuff may get a different meaning than before starting the sprint.

Answer 8

If you're familiar with one of the components then start with that. If you start with the one you don't know then by the time you're finished you might have forgotten all about the one you were familiar with and that makes it two hard tasks!