Ask HN: Worst part of programming/dev. cycle

Starting the code is hard, you either have to choose to be very careful in your original design or knowingly forfeit the code to future rewrites, both choices induce a certain amount of paralysis.

Then things get easy. Welcome to the flow inducing fun part.

Then the project is 95% done but you know massive amounts of effort will need to be expended buttoning this up. Knowing the abysmal ROI on this stage of the project tends to demotivate a lot of programmers. Its also the part of the project when most of the fun problems have been solved which demotivates even more programmers. This is where you identify who the finishers are (I'm not one) and man is it nice to have some finishers on your team, regardless of how little weight they carry through the first 3 phases.

I really only have experience with larger applications. In the few small projects I've worked on the first two phases were virtually non-existent since I, by default, have no problem throwing away something small.

Fortunately I really enjoy the first 3 phases. A lot of developers only like one or two... Welcome to the not so rosy world of getting things done.

Technical debt, simply put, is the result of poor choices made due to the lack of understanding (mostly the business domain; including current and future requirements) at implementation time. "Gold plating", not validating or being able to validate assumptions early on and not following best practices are the major contributors of technical debt. (overdoing it and not knowing what you're doing)

Determining scope is essential to any project. Adding unnecessary layers (e.g. localization, internationalization, n-tier architectures, following patterns blindly such as CQRS, leaky abstractions), insufficient layers/abstractions and not validating important assumptions lead to dramatic increase in lead times.

Apart from learning from others' experiences, I found that being accountable to someone you can trust to provide you with advice and scrutinize your approach to be invaluable.

As you gain more experience you will start trusting your gut more in regards to technical and business decisions. The other party can't always provide you with correct, complete or sometimes any answers at all and they trust you to do what's best for them.

In regards to the discovery process, it's all about communication. Ask them to describe in a document what they want (functional requirements), what problems they are trying to solve and what constraints are in place. If it involves workflow, ask them to describe their workflow and distinguish different roles and responsibilities. This should at least open up some avenues of discussion to resolve ambiguity.

Once you have a good idea of what's going on, start to compartmentalize the different contexts and iterate over each. See: http://www.productbreakdownstructure.com/

1) Design: More specifically, the models. I almost NEVER get my models right from the beginning. I don't know it's me or everybody, because you always start a program that will do ONE thing, then you decide to go modular. But how much modular? So I sometimes end up kinda lost in this back and forth.

2) Writing tests. For a series of reasons feels more like losing time than anything else, just to be like the cool kids. Maybe I just don't get TDD enough. At least I'm getting accustomed with RSpec syntax, scopes and everything else (RSpec is a ruby testing framework).

Other than that, I have more project ideas than I can count!