When working in a software development team, here are some things to avoid. How many are you managing?
Forgetting the definition of done
Whether it’s at the point of estimation, or at the point of moving on to the next task, if you do not factor in all the things it takes to sustainably build software, things will get harder and harder. You should include:
- Test automation
- Approval from your stake holders
- Build and deployment
In other words, it’s not just the coding.
Well my bit’s working
Inattention to the overall result means that everyone in your team can be personally successful, yet you end up with terrible software. If people understand the broader mission and are working to converge their efforts with it, then the software will hang together, not tear itself apart.
It’s great when people work hard, but not so great when they work harder and harder to provide things that aren’t needed, or take the long way around to make things that are needed.
How frustrating is it to build something under huge delivery pressure only to be told that it’s not needed anymore, or that it needs a complete overhaul to be fit for purpose.
Essentially: design and analysis can prevent a lot of wasted effort.
It’s always been like that
One of the classic sources of misplaced efforts is the assumption that the way we have been doing this is the way we should be doing things. It only takes a tiny incorrect bit of course setting at the start for things to deviate way off centre a long way down the road.
This doesn’t mean you have to be perfectionist and only start when things are perfect. It means, instead, that you should review each increment thoughtfully, and change the methodology, if necessary, once you are clearer on the benefits of one technique over another.
You should never rest on the comfort of something cumbersome and familiar, and should find something simple enough and powerful enough to use your time profitably.
These pull requests really mount up
What’s worse than making code that’s wrong? It’s making code that takes forever to get to production. Loads of unmerged pull requests represents various possible forms of waste in your process:
- Too high a WIP limit – so people are thrashing between tasks
- No commitment to completing things
- Keeping code that’s useless – just to be on the safe side (delete it!)
- Lack of confidence in code review
- Lack of confidence in test
- Lack of confidence altogether
- No process to track and complete work
- No prioritisation, causing rapid changes in direction
Release it or delete it.
Your review comments are YOUR opinion
A code review is a request for feedback, an opportunity to learn, and an opportunity to produce code that makes sense to more than its creator.
In general, people should make and receive code review feedback willingly. They should consider the points raised against their own code, and work out what’s best for the end result.
- Not engaging with code review is bad for the team
- Petty arguments over code should be avoided
- Look at it as an opportunity to achieve deeper wisdom in the subject
Yeah, the build does that sometimes
May our souls be safe from builds that don’t work reliably, especially ones which take especially long when they’re not working. You can lose hours a day to unreliable and troublesome builds. Here are some of the circles of build hell.
- Flickering tests
- Any build that takes longer than 30 minutes – ever!
- Most builds that take longer than 10 minutes
- Builds where failing tests don’t fail the build
- Builds that don’t always run when they’re meant to
- Builds with random failures and we’re not sure why
- Builds with predictable failures that we haven’t fixed, like it doesn’t really work when that other build is also running
- Builds with important parts that can’t be run locally
Your build is a slow feedback loop – it needs to be worth its wait/weight.
You may know some others. Let us know!