I Keep Making the Same Software Engineering Mistake

Photo by Brando Makes Branding on Unsplash

It isn’t inherently bad for software developers to think ahead.

You know, it should be part of our job.

Software development should reward work that pays attention to the details and follows the rules.

Yet I keep making the same mistake over and over. My crime against my Agile team is that I keep thinking ahead and trying to bring work into the current sprint.

It’s probably the most stupid thing that I do.

Let me explain why.

It’s such a crazy situation I think I need cigarettes and alcohol

As I sit here I’m looking at my work machine and refreshing. Why? We cannot merge any pull requests because the pipeline has been broken since Wednesday.

I’ve 5 reviewed requests waiting to go in.

My conclusion is that I shouldn’t be working this way.

Why I’m an idiot

Changing Requirements not factored in

In our super professional team, we oftentimes change requirements mid-flight. Not in an Agile way, but in a way that changes the scope of a ticket while it’s being worked on.

I usually press on committing my work, and then change to the updated requirements near the end of a ticket. 

Working now I can see I’m getting confused about which of my PRs have the “new” requirements. It’s a nightmare.

Working ahead at my own detriment

I feel ashamed about this. When I have some spare time, I usually pull in a new ticket.

I’ve had trouble in the past because I’ll work on a ticket in a sprint, but it can’t be tested so I’ll have done a bad😉. 

I’m a little bit wiser now. I’ll start to work on the ticket and not tell my colleagues. This means that I’ll be able to buy myself time for the next sprint, and have certainty that my work can be finished.

Then the requirement change inevitably comes (mid-ticket. Thanks Nathan).

That’s fine. I’ll just delete my branch!

Conflict with Agile Principles

Thinking ahead is essentially a contradiction to an Agile approach. It emphasizes flexibility and responsiveness to change and working sprints ahead goes against this. It simply does not make sense to be working ahead of a sprint, the work should be within the Sprint and you should give your all, doing the work in that Sprint.

Why It’s Everybody Else’s Fault

Parallel Development Encouraged 

Our scrum master keeps asking for parallel development on tickets. It doesn’t matter if you tell them that one ticket depends on the other, so naturally the order should be sequential.

This means that I need to say in each and every stand-up that I haven’t started TCKT-1394

I love repeating myself!

They love spikes here

I’ve never seen anybody work like this. For work that should take 2 days, they will spend 2 weeks seeing what needs to be done. That is, it takes longer to decide what work needs to be done than to do the work.

That reminds me of the worst thing about working here.

Testing takes forever

If it takes 2 weeks to decide whether to do 2 days of work, I’ve something more astonishing for you. That 2 days of work will take 2 weeks to test.

Conclusion

I’m an inconsiderate software developer who does not work well as part of the team.

You knew that already didn’t you?