

Ask HN: Worst part of programming/dev. cycle - cwt

What part of the writing a new app&#x2F;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&#x27;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.
======
kellros
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/](http://www.productbreakdownstructure.com/)

~~~
crpatino
> 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.

------
brd
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.

------
atmosx
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!

------
jordsmi
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.

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

