
Ask HN: Any framework to manage tech debt, increase quality – for small teams - raghava
Am trying to find if there any reference process framework&#x2F;guideline that small engineering teams could follow, to improve their engineering practice quality, in short, near and long term windows.<p>I have used the 12 step Joel test as a basic reference in a few places and found good success.<p>I am now dealing with a totally chaotic environment. (Think wild west of the olden days - no rules, no law) Seems like a daunting task, to carve order from chaos, but I believe it is doable.<p>Am sure many of us here would have dealt with such stuff. I need the help in form of larger wisdom of practitioners.<p>Please suggest! Thanks!
======
nojvek
I’ve worked at many startups and a high level principle i’ve found useful is
“introduce process when not doing it hurts more”

\- you could just work on flat files and sync with Dropbox. But losing history
and context hurts. Introduce version control.

\- hurts more to host your own git than just paying GitHub/GitLab. Do that.

\- Small prototype for startup. Don’t need tests. That’s cool. Ship to
production directly. Now you have customers and shit is regressing and pissing
customers off. Introduce CI so every merge with master has some level of
quality.

\- Now you have multiple team members all committing code at various levels of
quality. Make sure they reviewed by people who have code context and know what
good code is. Pull requests and reviews for merges.

\- people don’t know what to do. What is highest priority? what is the scope?
what are the unknowns? how long will things take? Introduce something like
trello or any other task management system. Work against goals broken down
into tickets and plan in small increments.

\- shit goes on fire occasionally. Have an oncall rotation. Monitor metrics
and alert if something needs investigating.

~~~
davismwfl
This is definitely a good approach, totally agree with it.

It is bad to introduce too much process too early, and a good measure of when
you need it is when the pain of not having it exceeds the pain of the process.
I really dislike unnecessary process, but as you grow different processes
become necessary and they make life easier and more predictable.

It isn't rare to have the wild west at a startup in the early days and it
isn't rare to lose a few people when you start putting in necessary processes
because they don't want the constraints. One of the most valuable lessons I
have learned over the years is that it is healthy when people leave that
aren't on the same growth path or maturity of the organization. Don't fight to
keep people when this is the case, it just adds stress to the organization and
people internally know that the person isn't a good fit anymore. So let them
go. Hard thing to do sometimes, but necessary as companies grow and mature.

~~~
raghava
> it is healthy when people leave that aren't on the same growth path or
> maturity of the organization

Yes. That's real!

~~~
config_yml
Yes, and it works in both directions of the relationship.

~~~
davismwfl
Completely agree, both the company and individual win here, no one wants to be
unhappy doing their work. And no one wants to work with the person that is
always complaining about how the company has changed.

------
president
The core of the issue is usually the team culture, mindset, and expectations.
If things are as chaotic as you say, then you need to identify what is the
cause of the chaos. Some possible scenarios:

1\. Ignorant leadership has led to a culture of not respecting software
engineering best practices.

2\. Engineering team is ignorant of software engineering best practices.

3\. Team understands best practices but culture is such that there is no
time/incentive to implement them. This could be due to people being overworked
and as result, prioritizing for delivery and only being able to focus on
things other than fixing tech debt. It could also be due to the fact that
bonuses are given to those that are implementing new features into the
product, therefore creating environment that values delivery over proper
software engineering.

You need to figure out what the reason is for your team's tech debt chaos and
only then will you be able to fix the problems. There are also degrees of tech
debt that you need to consider (architectural-level tech debt vs unit-level
tech debt) that will play into what things you can do to rectify the issues
and prevent them in the future.

------
peterbozso
Most of the important points have already been raised by others (version
control, CI/CD, etc.).

I would only like to recommend one specific tool, which you can integrate into
your CI/CD pipeline: SonarCloud
([https://sonarcloud.io/about](https://sonarcloud.io/about))

The on-prem version is called SonarQube
([https://www.sonarqube.org/](https://www.sonarqube.org/)) which you can
easily host yourself if you need/want to, but the cloud version is dirt cheap.

This single tool can bring tremendous value into your work life, especially if
you have a team full of junior/inexperienced people. It has saved me countless
hours on different projects by providing actionable insights on their code
bases.

Disclaimer: I have no ties to the company making SonarQube, I am just really
thankful that this tool exists. :)

~~~
raghava
Thanks for the pointer. I will certainly explore if that works well with a
hosted gitlab instance.

I understand the value of static code analysis very much. Alas, I cannot start
talking about things like cyclomatic complexity of code, or water-tight
dependency mitigation and its impact on quality/cost-to-company/risk, as the
audience isn't mature enough to really grok it.

------
bfrit
I introduced a thin process at my last job called "capacity setting". It's
more abstract than just tech debt, but highly autonomous while still being
aligned to the company's needs and goals - including making it clear on one
page what the team is working on and why. It worked out reasonably well as
Tech Leads were able to control capacities and the business was able to see
justification of why we're working on various elements and how much of each.

Here's the brief. Will be glad to answer any questions.
[https://drive.google.com/file/d/1-ej-
qOCYIaNHJITq8wiMj0hZTFK...](https://drive.google.com/file/d/1-ej-
qOCYIaNHJITq8wiMj0hZTFKSxYHS/view?usp=sharing)

~~~
raghava
> capacity setting

Very interesting. Will surely read it and reach out if questions arise.
Thanks!

------
cbanek
Don't look for a silver bullet. Find the largest cause of chaos and try to
solve it in the simplest way, which may be a manual process. Some things that
cause chaos are: no CI, no tests, no code review, etc.

Trying to add some kind of process or framework is likely to just suck more
energy out of the system and make the ICs think you're wasting their time. If
anything, they know what they need to do, but probably are being pushed to
ship or do something else. Nobody likes to live in chaos.

~~~
raghava
> Don't look for a silver bullet.

Have cut my teeth long enough to know that there's no silver bullet (except in
a 'con'sultant's marketing brochure, that is! :D)

> Trying to add some kind of process or framework is likely to just suck more
> energy out of the system and make the ICs think you're wasting their time.

Absolutely. Point taken!

> Nobody likes to live in chaos.

Unfortunately, few do want to, cause it makes them look like heroes. And
that's where the problem arises. These fellows to nurture their heroic image
end up ruining it for everyone, and worse - make the org just stagnate in a
limbo.

~~~
cbanek
Almost sounds like you have a cultural hero issue? This happens a lot. I think
some of it is because people praise people who work extra hard, rather than
those who finish their work quickly and well and rarely have to come back to
it. Maybe reinforcing good process and looking at things like bug count might
help prevent the heroes. Or ask them "how can we make it so next time we don't
have to work all night?"

Maybe let the heroes own the solution so that they are still heroes after
implementing the thing that fixes everything?

Culture is probably the hardest thing to turn around though. But so important!

~~~
raghava
> Or ask them "how can we make it so next time we don't have to work all
> night?"

That's a good one; will certainly use it! thanks!

------
virjinia
Hi, glad to hear you are using GitLab! Would love to get your feedback on a
couple of things we are working on, which I think can help out: \-
[https://gitlab.com/gitlab-org/gitlab-
ee/issues/12196](https://gitlab.com/gitlab-org/gitlab-ee/issues/12196) \-
[https://gitlab.com/gitlab-org/gitlab-
ee/issues/12260](https://gitlab.com/gitlab-org/gitlab-ee/issues/12260) \-
[https://gitlab.com/gitlab-org/gitlab-
ee/issues/12683](https://gitlab.com/gitlab-org/gitlab-ee/issues/12683) \-
[https://gitlab.com/gitlab-org/gitlab-
ee/issues/12079](https://gitlab.com/gitlab-org/gitlab-ee/issues/12079)

------
he0001
One thing I think is forgotten or neglected, particularly when you are a
startup, is to learn your tools. If there are too many, cut down on them or
isolate it’s code impact. Having too many tools/frameworks around increases
the level of cognitive load and how to use them thoroughly. I’ve seen too many
times where there are several different tools solving the same general problem
interfere with each other because the coders don’t know that one would be
enough.

~~~
raghava
Yup. This is certainly one problem that we are dealing with.

JIRA - so that non-tech folks can be on-board. Documentation is virtually non-
existent - even though there's wiki on git.

git for DVCS, but done in a haphazard way.

Bug tracking on JIRA, as tasks.

Operations/customer success/top management still depending on excel sheets for
reports.

End result: cognitive load on apt way of tools usage is very high, and also
puts a high barrier of entry and adoption in the right way.

------
andrei_says_
I’ve been reading Basecamp’s Shape Up / stop running in circles and ship work
that matters.

My twitter feed showed a few shops which implemented the process and are happy
with it.

[https://basecamp.com/shapeup](https://basecamp.com/shapeup)

~~~
raghava
> [https://basecamp.com/shapeup](https://basecamp.com/shapeup)

Thanks, that's a really useful resource!

~~~
fillskills
In addition to ShapeUp (which is awesome btw), I would like to add Gitlab's
Handbook:
[https://about.gitlab.com/handbook/product/](https://about.gitlab.com/handbook/product/)
[https://about.gitlab.com/handbook/](https://about.gitlab.com/handbook/)

~~~
raghava
hmm, this is useful too! Thanks

------
tehlike
Release early, release often and fast.

Stability and quality relies on rapid iterations. Optimize for that.

------
codesushi42
Conformance tests, code reviews and ACLs for check-ins.

It's the only way.

~~~
raghava
hmm, agree. Am still figuring out the way to bring these in, without adding
more chaos to an already chaotic system. :)

~~~
codesushi42
There is no way to do this gradually.

Don't try to get everyone's buy in. You won't.

This needs to be enforced from the top. And immediately to stop the bleeding.

~~~
raghava
> Don't try to get everyone's buy in. You won't. > This needs to be enforced
> from the top. And immediately to stop the bleeding.

Yup. Sounds reasonable.

