Ask HN: Worst part of programming/dev. cycle | Hacker News Reader

Ask HN: Worst part of programming/dev. cycle

3 pointscwt6 comments

What part of the writing a new app/program gives you the most grief? That is what is the hardest part for you to overcome? Does it depend on the size of the project? Are small projects hard to start but easy to finish? Large projects easy to start but hard to finish? I'm a young developer and find that getting started - the discovery process - is where I have to battle ennui. Things are still too abstract at this point and its easier for the mind to wander. But, once I get started writing code the process becomes much more enjoyable.

View on HN

I find the hardest part in any project is avoiding and getting rid of technical debt early on.

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/

> I find the hardest part in any project is avoiding and getting rid of technical debt early on.

If you have struggled with that, you will love inheriting and refactoring 10+ years of technical debt... on a shoestring... due tomorrow.

Initial planning is hard, especially when working out scope with other parties.

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.

Two things:

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!

My biggest issue is deciding the scope of the project. In the beginning I have an idea and it seems possible. After a few days of planning I just turn it into some extremely complicated thing and just psych myself out of it.

I have a hard time staying on task instead of reading HN all day. Focus, focus, focus, get stuff done.

Reply on news.ycombinator.com