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.<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!
I’ve worked at many startups and a high level principle i’ve found useful is “introduce process when not doing it hurts more”<p>- you could just work on flat files and sync with Dropbox. But losing history and context hurts. Introduce version control.<p>- hurts more to host your own git than just paying GitHub/GitLab. Do that.<p>- 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.<p>- 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.<p>- 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.<p>- shit goes on fire occasionally. Have an oncall rotation. Monitor metrics and alert if something needs investigating.
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:<p>1. Ignorant leadership has led to a culture of not respecting software engineering best practices.<p>2. Engineering team is ignorant of software engineering best practices.<p>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.<p>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.
Most of the important points have already been raised by others (version control, CI/CD, etc.).<p>I would only like to recommend one specific tool, which you can integrate into your CI/CD pipeline: SonarCloud (<a href="https://sonarcloud.io/about" rel="nofollow">https://sonarcloud.io/about</a>)<p>The on-prem version is called SonarQube (<a href="https://www.sonarqube.org/" rel="nofollow">https://www.sonarqube.org/</a>) which you can easily host yourself if you need/want to, but the cloud version is dirt cheap.<p>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.<p>Disclaimer: I have no ties to the company making SonarQube, I am just really thankful that this tool exists. :)
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.<p>Here's the brief. Will be glad to answer any questions.
<a href="https://drive.google.com/file/d/1-ej-qOCYIaNHJITq8wiMj0hZTFKSxYHS/view?usp=sharing" rel="nofollow">https://drive.google.com/file/d/1-ej-qOCYIaNHJITq8wiMj0hZTFK...</a>
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.<p>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.
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:
- <a href="https://gitlab.com/gitlab-org/gitlab-ee/issues/12196" rel="nofollow">https://gitlab.com/gitlab-org/gitlab-ee/issues/12196</a>
- <a href="https://gitlab.com/gitlab-org/gitlab-ee/issues/12260" rel="nofollow">https://gitlab.com/gitlab-org/gitlab-ee/issues/12260</a>
- <a href="https://gitlab.com/gitlab-org/gitlab-ee/issues/12683" rel="nofollow">https://gitlab.com/gitlab-org/gitlab-ee/issues/12683</a>
- <a href="https://gitlab.com/gitlab-org/gitlab-ee/issues/12079" rel="nofollow">https://gitlab.com/gitlab-org/gitlab-ee/issues/12079</a>
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.
I’ve been reading Basecamp’s Shape Up / stop running in circles and ship work that matters.<p>My twitter feed showed a few shops which implemented the process and are happy with it.<p><a href="https://basecamp.com/shapeup" rel="nofollow">https://basecamp.com/shapeup</a>