Category: Leadership

Bugs

Despite what your boss might like to think, Bugs are a fact of Software. There’s a number of things you can do to minimise the occurrence, the severity and the impact bugs might have, mostly centring around having a reliable set of Unit Tests. Regardless of your best efforts, they will still find a way through the net, it’s how you handle them that matters.

Be Honest

My first piece of advice would be to be honest about them, and the root cause, however embarrassing to you or your team it might be. It’ll be too late to cover it up, so don’t waste your time thinking of excuses. Get to the root cause and come up with a plan to resolve it. If it’s a major problem in Production it’ll be on your shoulders to come up with a strategy to expedite a resolution. Continue reading “Development Team Leadership First Steps : Part 12”

I recently read The Software Craftsman, as mentioned in the review, one of the areas that struck a chord with me was the viewpoint on Legacy Code. I deal with a lot of Legacy Code in my day job, I’ll share a few of my own thoughts and experiences on the matter.

Legacy Code – Respect

It’s important to treat Legacy Code with Respect, from all angles. Treat it with respect regardless of how poorly some of the code may have been written, or how antiquated the technology may now be.

Don’t take requirements on Face Value

Often your requirements can overstep outlining the business need and into murky waters of business users defining technical solutions; which are rarely the way we would choose to do it, or in some cases even technically feasible.

“Has the world gone mad; or is it me?” – Ben Howard

As professionals it’s our obligation to probe these requirements until we’re left with something that makes sense that all parties are happy with. It’s always worth asking why, sometimes a requirement can disappear altogether as a result.

Bigger Picture

Make sure you understand how the component you are writing fits in with the architecture as a whole. As the Development Lead you’ll be expected to be capable of participating in conversation with all areas of your team and all levels of the business, from those with a vested interest in a particular piece of functionality, all the way up to those who aren’t interested in the minutiae, just the fact that the system works.

If you don’t understand how your software fits in with the wider Organisation you won’t be able to fulfil this. Again, if you can prove your understanding you’ll gain trust, but it’ll also enable you to more conclusively understand requirements if you understand for example what impact your validation (or lack of!) may have on downstream systems.

Are we there yet?

You’ll inevitably be asked (“probably” by Project Managers, and “probably” numerous times) whether you’ve finished a Task, it’s nice to have an answer to hand about not only your own work, but that of the team. Having a visible board to track progress on is really part of the Agile process, having one of these can ease the pressure, (but that doesn’t mean you won’t be asked!).

Not only is it good to have an answer to questions, but if you have an idea of whether your team is likely to finish all of the tasks on your current sprint then it will allow you to raise the alarm early, or re-prioritise workload within the team.

Constructive Criticism

Something I’ve seen many people struggle with is the ability to take constructive criticism, and inversely offer it.

Giving Constructive Criticism

I’ve previously recommended being free with advice. An extension to this, and a vital leadership skill is the ability to critique a colleague’s work without causing offence. Obviously being rude about someone’s work will alienate them and earn you no favours, but it’s often the case that a colleague won’t quite have understood the direction in which you wanted them to head with a certain task. There’s a couple of things personally you can take from this : Continue reading “Development Team Leadership : First Steps Part 8”

Pragmatism – Take your time

I’m sure you’ll have heard the saying :

Rome wasn’t built in a day…

…and it’s fair to say that 99% of the time, neither will your app be. Be realistic regarding what you can achieve and by when. Everything about the Agile methodology points to being able to work sustainably, and getting better at doing so along the way. There’s many articles about picking a vertical stripe or horizontal stripes through your architecture and delivering a concise set of functionality. My advice would be, don’t let your chosen stripe get too fat. If you can’t hit an imposed deadline, be honest and say ‘no’.