HN Explorer

Ask HN: Any framework to manage tech debt, increase quality – for small teams

29 points by raghava ↗ HN
Am trying to find if there any reference process framework/guideline that small engineering teams could follow, to improve their engineering practice quality, in short, near and long term windows.

I have used the 12 step Joel test as a basic reference in a few places and found good success.

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.

Am sure many of us here would have dealt with such stuff. I need the help in form of larger wisdom of practitioners.

Please suggest! Thanks!

29 comments

[ 3.2 ms ] story [ 77.7 ms ] thread
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

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.
raghava
Superb set of points; thanks.

Current state: 1. version control [done; branching strategy and flow to be honed] 2. self-hosted gitlab [least of our worries, hasn't hurt to run, so will continue self-hosted] 3. regression has become a serious problem [will push for CI] 4. code/design/architecture/bugfix reviews [will make it more formalized] 5. better prioritization and reduced randomization [will push more for this] 6. on-call roster [will work on formalizing it]

Again, thanks for great pointers.

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!

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

raghava
> capacity setting

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

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.

ajeet_dhaliwal
If you add tests, especially when you get to hundreds or thousands it can indeed get chaotic, try Tesults (tesults.com) for managing them along with results. Contact me if your team is very small for freebies (I’m associated).
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)

The on-prem version is called SonarQube (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.

Can_Not
The sonar eslint plugin is great, too.
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.

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.

tehlike
Release early, release often and fast.

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