<p>You know that particular part of your code that is essential for the project but will probably take a lot of time to get it done? Do you ever get the feeling that you'd rather work on something else (probably less important) or not code at all instead of working on that part? That beast you try so hard to avoid and use every lazy trick you know to delay its inevitable implementation? </p>

<p>Now, I'm probably just being lazy, but I've always had to deal with code like that. Write something I don't feel like writing (and it's worse if you're doing it for fun and not getting paid!). A large system that will take a lot of time to get it into a stage where you get back any useful results or indication of it working. How do you start coding something like that? Most people would probably suggest divide and conquer and similar architectural techniques, but this isn't about how you do it; it's about how you get yourself started on doing it. What's the very first steps you'd take?</p>

I agree with you that many large, important parts of a software are not fun to write. I usually start my development day with some smaller things, like adding a feature here, or fixing a bug there. When it's time, I start with the large part, but when I just can't see the thing any more, I do something different. That's all fine if you still get everything done on time. And remember that it may make things easier if you talk with other people about that large beast before you're doing it, while you're doing and after you're done. This will not only free your mind, but you'll also get other people's opinion from a less subjective point of view. Planning such things together also helps.