
Failing (and winning) at planning software projects - marcoow
https://simplabs.com/blog/2020/06/17/failing-and-winning-at-planning-software-projects
======
mikece
When was the last time the functionality and scope of an application was
defined BEFORE it was built (and didn't change before shipping)?

The longer I program the more I like small, simple apps that can be chained
together to do useful things... and be completely re-written at a later time
when the full needs of the company are actually understood. What makes that
re-writing or re-architecting a lot easier is clear documentation and modeling
of the system at a high level, who the actors are, and what the
essential/primary, secondary, and tertiary functions are as well as giving a
score that reflects how essential each is to the company's core business (eg:
a login/auth system would rate very low unless your product or service is a
login/auth system -- this is a component that can/should be outsourced so you
can focus on what makes money for your company).

Write the app "just good enough to work and make money" but document the
business as completely and clearly as possible with the assumption that at
some point in the future a team that's new to the company could write a
complete replacement of all of your software (which might just happen if you
are successful enough to get a massive investment and need to rearchitect for
future growth).

------
berkes
> Actively keeping a backlog is most often simply a waste of time. That is not
> only the case for feature tasks but also for bug reports – a bug that has
> not been addressed for the past six months is unlikely to be addressed in
> the coming six months.

This makes me uncomfortable. I don't exactly know why, but the thought that
ideas, nice-to-haves, and bugs move to a /dev/null of some sort, does not
resonate with me.

What if that bug re-appears after 7 months. You'd want to pull up the old one
and go: "see, it still hardly ever happens, but here's another one".

You could rename the backlog to "archive", but that hardly makes it different:
a backlog is still a list of stuff you had no time to think about.

~~~
marcoow
Not maintaining a backlog doesn't necessarily mean you cannot collect ideas
etc. anywhere. I think the two main points are:

* putting effort into preparing proper tickets for all these ideas is likely wasted time as 90% of the ideas will never be taken on * keeping all the ideas together with the issues that are actually important creates noise and makes it harder to identify the actually important stuff; also having a backlog with thousands of open tickets puts loads of emotional pressure on teams since they are always feeling like they lack behind while in reality most of those thousands of tickets are irrelevant anyway.

Also I'm not sure what the point of being able to say

> "see, it still hardly ever happens, but here's another one".

would be really (except for being right about the existence of something) – if
the decision is not to fix the bug it's irrelevant still.

~~~
maaarghk
[https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-s...](https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-steps-to-better-code/#:~:text=5.%20Do%20you)

~~~
marcoow
Sure, you should have bugs documented somewhere but I'm not sure a bug that
hasn't been fixed for x months needs to be there since it's a bug the team
obviously decided not to care about.

~~~
watwut
I personally fixed bugs that have been opened for longer then that, so nope,
they can get fixed. Plus, it prevents people from opening them again and again
and again and again as they all notice the same thing.

~~~
cpeterso
I've fixed a couple Firefox bugs that were filed in Bugzilla 10-15 years ago.
:)

At least one fix, however, upset some people who come to like the "incorrect"
behavior over those 10-15 years. (In one case, I changed the filename of saved
web pages from "index.html" to HTML <title> .html to match Chrome and IE
behavior.)

This xkcd comic is relevant: [https://xkcd.com/1172/](https://xkcd.com/1172/)

------
stephc_int13
"other stakeholders that have legitimate needs with regards to predictability
and insight into a project's progress are left in the cold"

Well, that's a bit dishonest, this is not really about coordination, this is
about risk and money.

This is about helping people who are not working on the project to sleep
better.

I believe that setting the budget and deadline from the start and then asking
the team to scope the project is a reasonable way to manage risks, but not the
other way around.

~~~
commandlinefan
> not working on the project to sleep better

I believe it's more sinister than that: it's to prevent the people who are
working on the project from sleeping at all. Remember, most developers are on
a salary, which means minimum 40 hours a week, but a maximum of 168. People
who view other humans as expendable "resources" \- the amoral types who
inevitably rise to prominence in corporate America - then see planning as a
strategy to push that number as high as possible. They thus insist that an
inherently unpredictable process - software development - must be 100%
predictable and, when that inevitably turns out not to be the case (yet
again), they demand punitive uncompensated overtime. This isn't an accident.

~~~
marcoow
Hey, I’m the author. I think you Mis-interprete what I’m saying - of course
understanding timelines and budget will often be a legitimate need of one or
some stakeholders, among others. And of course making teams stick to deadlines
when that’s not possible is bullshit. But the other extreme - demanding that
nothing can ever be estimated and understood well up-front - is equally wrong.
In the Limited scope of an iteration, it is well possible to reduce risk and
uncertainty at least a good amount through thorough analysis and preparation.

~~~
stephc_int13
I disagree, in my opinion it is never legitimate to pressure people into
predicting the future, and it simply never works.

There is a very this counter-intuitive thing about predicting the future.

We tend to believe that by cutting our predictions in smaller and smaller
pieces, our predictions will be closer to reality, or at least more
manageable. But there is nothing further from the truth, the best predictions
are made when someone experienced in the field is looking at the big picture
and try to give a rough estimation.

This has been proven again and again.

At the end od the day, people are working and projects gets finished not
because, but in spite of micro-management and other unhelpful practices.

~~~
marcoow
Indeed we disagree. I’d say the reluctance that’s relatively wide spread in
particularly among engineers to even try and reduce risk as much as possible
(within a limited scope) and framing that as „predicting the future“ is a huge
fallacy that doesn’t benefit anyone. There’s just not only the 2 extremes -
completely and reliably predicting the future vs. just going off with no plan
- but there’s something in the middle.

Also the big picture That one could look at in the beginning of a project and
base an estimate on is more often than not not what you end up with at the end
of the project anyway.

~~~
stephc_int13
My main craft is software engineering but I've occupied managing roles in the
past, and even twice as the CEO of a small company.

I am perfectly aware of the difficulties of managing projects and keeping
clients happy.

From my experience, what you are describing is something few founders are
concerned about, because they understand and embrace risk.

On the other hand middle-management is always trying to push their peons to
predict the future and accept the liability.

~~~
marcoow
> On the other hand middle-management is always trying to push their peons to
> predict the future and accept the liability.

That's bad just middle management then though. It's also why I'm advocating
against project managers who would typically/often/sometimes do what you
describe here – if you have someone who doesn't actively contribute to the
project influence (or dictate in the worst case) timelines, that's deemed to
fail from the beginning.

------
marcoow
Planning and estimating projects (or sprints within projects) is associated
with a lot of uncertainty and frustration on all sides. At the same time,
teams feel they have to adopt processes like Scrum (or their own
interpretation of it) and then expect that to fix everything which is usually
not the case of course. In reality what I find lacking in most teams is direct
communication and close collaboration as well as an appreciation for the valid
and reasonable needs and interests of each and every project stakeholder
(that's not only engineering and design but also product, marketing, finance
maybe etc.).

In this post, I present a set of relatively simple techniques to practice that
remove a team's frustration and enable better estimates and predictability.

