4 ms·
Ask HN: Change from a quick and dirty rusher to be rigorous and conscientious
I'm the technical co-founder of a start up that looks like it has real potential. My partner knows the business domain and is a good salesman and we have a couple of others who help part time.
Every time we release non-trivial features things break on production. Bugs surface regularly and our customers like our system but don't consider it stable, they notice the stream of problems. I think this is the only thing that is stopping us growing dramatically in the next 6 months.
I am a procrastinator. I avoid doing the sensible and important things that I know I should do, such as creating an automated test suite, writing up detailed designs and walk-throughs. I wait until a feature is required and when the urgency reaches a certain point I start working through the night to get it done.
It really hurts me to see myself serving up work that I know is crap. I don't leave myself enough time to do things well.
How can I hold myself to a higher standard.
Ideas :
- I must practice not running away from anxiety and sticking with my work. I think anxiety causes procrastination.
- I need to jump on board with testing. We need to create tests for all new code and not worry about whether the tests hit the db, are in the best structure, use the page object model, include headless browser testing or not. I have ummed and ahhed about this stuff for so long, I need to just get started.
- I need accountability. I need to arrange scheduled reviews of our development process to check if it's improving.
- I need a single place for all tasks, issues, bugs and designs, I will go with Jira.
- Every significant feature needs a UI design, some code high level design and a review before dev starts.
- I need to stop committing to deadlines. Being a people pleaser I am amazingly unrealistic about how long things will take and set myself up for failure.
All suggestions appreciated.
000000000000000000
- devnonymous 10y agoI know where you're coming from. Had it not been for the company of colleagues who had been doing reviews, test, CI, refactoring sprints etc for a long while to attest to its benefits, I would have become overwhelmed at the prospect of adopting these practices. Here are some suggestions based on my personal experience : * Don't try to do it all. Do it a step at a time. Choose what's most important for you and work on that. Maybe it is CI. Which in real terms implies automated building, testing and deployment to staging for every commit. Or it could mean writing tests for the most fragile parts of the codebase. Whatever it is, pick one. Start small. Else you'll end up with just another 10 things that you've also got to worry about. * Dedicate time, resources and a developer only to focus on this one thing. If your team is small or it is just you, hire someone to get this one thing done. * If you are not already doing it don't bother with core review meetings at this point. However integrate static checkers/linters in your commit workflow. Then move to a 2 ack process. Then do proper code review meetings (if necessary) (updates, since I am writing this in parts) * Don't enforce policies that will lead to frustration but do enforce policies that just might be a bit inconvenient. * Don't expect immediate improvements but don't stop midway, you'll probably end up in a worse situation than now if you do.
- Devdealer 10y agoThanks devnonymous. I will make getting a test suite for core functionality my number #1 priority and then investigate static analysis tools and CI. Do you have any links that explain what a 2 ack process is in this context ?
- sharemywin 10y agomake a backlog of everything. don't take on too much, but deliver what you promise. 1. critical issues - work on those first 2. defects and new features 3. process improvement - spend 10-20% on these or things will never get better. setup a test environment makes sure everyone is testing. 1. create a smoke test of critical features 2. test those and new features every time you deploy
- Devdealer 10y agoThanks! I think this sums up well what I need to do.
- brudgers 10y agoThere's no moral/ethical/character shortcoming/failure/flaw here. The company has leveraged technical debt. The leverage has allowed the company to grow. The debt increases the likelihood of bugs. Technical debt is a business decision. It's use is a sign of technical competence, not incompetence. Customers complaining is better than not having any customers. The business goal is not some bug free codebase. My random advice from the internet: 1. Accept technical debt for what it is. A business tool. 2. Talk to the customers. If stability matters more than new features, focus on stability. 3. If stability isn't your customer's overwhelming priority, keep moving forward iterating on their feedback. What you are doing is hard. The good news is that there aren't grades every three months. It's a marathon not a sprint. For a startup, technical debt will tend to disappear in one of two ways: the startup shutters its doors or the startup grows to a scale where even original systems with zero technical debt would have to be redesigned. Then you have to build Kafka or Kubernetes or Wasabi. Good luck.
- Devdealer 10y agoThanks brudgers, I appreciate your input. I think there is some truth in what you've said. However in my case it wasn't a conscious choice, in fact my conscious choice at many points along the way was to improve quality, stability, reduce bugs that make to production etc. And I haven't done it. So I cannot claim quick and dirty was as strategy. I would have been ok with that for the first 6 months but we are past that. I want to face up to the fact that I need to change. Also I have a suspicion that doing things well becomes faster and more efficient than quick and dirty quite quickly. Thanks for your words on encouragement.
- brudgers 10y agoI am curious what the business case is for the intended change. It seems to be missing from the described context.