Ask HN: How to set up SD practises and processes in a startup as a senior dev?

2 points by sanketskasar 5 years ago | 2 comments

I am working with an enterprise SaaS startup that is about a year old. They have the product validated, conducted some pilots and are now into the revenue and growth phase. The founders don't have enough knowledge/experience about software development. Initial they hired developers who could create a working system but without any systematic organisation and practises like testing or code reviews. I joined a few months back and seen the code-base get uglier day by day and all I have done till now is ask people about technical documentation for every feature/fix they code, writing tests and following proper branch structure in git so as to merge the code with a peer review. But nothing such has been happening and I am afraid, we will reach a stage where making changes to existing code will ensue lot of side effects. It is my responsibility now to make sure these processes are setup and followed by all the devs. Given that its a small team of 7-8 devs, it should be easy to enforce these practises but that hasn't been the case. How do I go about it? How do I make sure that business execs don't pressurise the tech people enough to cut corners and flung the process? As a not so experienced developer, what are other things I should focus on? And is it possible to implement this without taking a hit to productivity?

komon 5 years ago |

You gotta sell everyone involved in the benefits.

Convince the devs that you're not just giving them make-work to do, get the execs to buy in on giving you the space to do what must be done.

Keep the pitch focused, you're not selling them on a rewrite after all, just on better practices.

A code review process means fewer defects and better ramp up on changes made across the code base.

A clean codebase is going to make future changes easier, faster, and less buggy. It's also going to help with engineer retention.

Execs don't really care about fiddly perfectionism or process or even technical debt. So speak their language.

Engineering can be done on short notice, but running up the pressure is only going to result in a broken product. If you can't get the execs to stop pressuring developers directly, it's a lost cause.

For the devs, they need automation and clear benefit. If you just tell them to start doing code review it writing tests, the starting friction is going to be too high.

Instead, give them working PR templates that reduce how much typing they'd have to do. Give them build scripts that test the code cleanly in one step. Plan some mob programming sessions and write some tests together.

Most importantly, you have to get everyome on the team in a (virtual or otherwise) room and have them choose the standards themselves. You can't mandate things like test coverage percentage targets or code formatting standards without the devs feeling like it was something that they all agreed on.

Then, make it your personal business to follow up with automation to back it up. Get some plug and play static analysis tools in there to enforce whatever test coverage minimums were agreed on. Build formatting and linting into a pre-commit hook so they never have to think about it. Take as much friction as you can it of it so that even the most pressured dev can see the value in writing some tests for the new feature.

You have to get them from agreeing to trying it these new processes to getting value out of those processes as quickly as possible.

brudgers 5 years ago |

Make a business case to the business execs. There is not one in your description...slowing down productivity because the code base is "ugly" doesn't cut it. A future where it is hard to change the code only happens if the busines survives and grows to the point where that's a problem...and if the company really grows well, then even a pretty code base will probably get chucked when the new problems that only come with scale dominate. Good luck.