12 reasons why I love software development

1 Automation means fixing it once.

Although please note that fixing it once doesn’t mean always fixed. I’ve got a 20 year old Mandelbrot generator that still works but I’ve had to tweak as the C compiler evolved. The algorithm is the same, but I had to modify the implementation slightly as GCC changed how it handled the standard library.

2 Working with smart people.

If you’re scared of learning, this isn’t the job for you. Experienced people will show you solutions you’d never thought of, everyone will ask you questions that cause you to re-evaluate your decisions, and you’ll find yourself saying “I don’t know” more often than not. If you think you know everything, you haven’t even started.

3 Variety

Once a problem is fixed you move on to new domains and new problems. You need to grok new domains, learn new technology, analyse how you work and adapt.

4 Alternative perspective

Software development reaches into many aspects, and covers a variety of topics, so allows healthy discussions across disciplines. (commit strip cartoon?) How you see a process or a program is likely not how the users see it. Human processes are messy and full of holes. Sometimes we can fill them, sometimes we just have to let the users work around them.

5 Meritocracy

(Disclaimer: I realise I’m talking from a position of privilege, and this may not reflect everyone’s experience)

All the teams I’ve worked in are judged on their ability to deliver good software, not colour, gender, age, disability or otherwise. People are praised on their ability to deliver and to work worth others, and criticised when they fall short. I realise I only see a small proportion though, and I did work as a STEM ambassador and a youth club volunteer to help broaden the pool. There’s a lot of work to be done, but good teams benefit from the diversity, and recognise that. If your team doesn’t, fix it. And help get out there to fix it for all teams.

6 Pride in seeing our work being used.

I’ve worked on projects to distribute EU funds to projects around the country, to track prisoner learning to make sure they could get qualifications, to model factories and save companies millions, to help people navigate their bankruptcy, to help nurses and managers find inefficiencies in hospitals. The software I’ve worked on its being used by people for whom it makes a real difference. There’s few jobs that allow you to impact so many people, in so many different ways.

7 Multi-disciplinary

Software development touches on many disciplines, and successful software projects provide opportunities to discuss ethics, psychology, politics, law and other areas. There’s a lot of specialism, but if you want to understand your users, and understand security, and understand the requirements, you often need to dig in and uncover answers from many disciplines to truly understand what you’re building.

8 Satisfaction

It’s clear when a problem is solved. It might not be clear when a project is finished, but each step on the way should be a clear, this is Done. If you don’t have that on your team, define Done. That’s your route markers so you know you’re making progress.

9 Mentoring

It’s great to see others catch on. See them awaken to the fact that there’s so much more to learn, that software development is a rich, diverse discipline, and then see them run in a direction to become the expert you seek advice from in their chosen area.

10 Challenge

Sometimes the satisfaction from development comes from tackling hard problems with no easy answer. Knowing that no-one has solved it before. Land on your own moon.

11 Communication

There’s always someone interested in what you’re doing, and there’s multiple international communities. There’s websites and forums, user groups, conferences. Lots of opportunities to engage with others and learn and teach outwith your company circle.

12 Changing the world

Software has become the driver for most of our daily lives. Without it, there would be no smartphones, no Internet, no social media, no video calling, no Uber. If you want to change the world, first you must understand it.

Advertisement

Killing legacy code

Michael C. Feathers defines legacy code as code without tests. I find it’s also likely, as a consequence, to be heavily coupled, with deep tendrils interconnecting multiple components. Indeed, many of the patterns in his Working Effectively With Legacy Code are about how to sever those tendrils safely in order to test the components individually.

But sometimes it’s about cutting out dead wood, that once-central code that’s outlived its usefulness and whose self-importance is infecting global configuration and the architecture.

The code that has special conditions in the API and would likely be more stable if it was split into smaller chunks.

Many of the techniques are the same as you’d use to get the system under test, add wrappers so you can redirect to null implementations, ready to remove all the calling code; replace global variables with more appropriate scoping.

So you get the code working, and passing the tests, so you’re comfortable that it’s removed, but then you have to deal with the orphans. The homeless configurations, the stateless variables, the untouched methods, that look like they should be free to go, and aren’t referenced anywhere. Except there’s some stringly typed calls, or rendering of inputs, that might, just might, use that code.

And they sit and rot.

Until you profile, and analyse, and kill off some more.

And you rewrite the input handlers to ensure nothing can be constructed to hit them, and kill off some more.

And then something breaks, and you’re too scared to touch any more, because of quantum effects.

And then you add new generic error handling so you can remove some more.

And then you rewrite it.

Bootstrapping into a team

I’ve created teams from scratch and been brought in or promoted to lead existing teams. I’ve made a few mistakes, especially when starting, and I hope sharing them with you will help you to help your team faster.

Responsibility

When I started out, I often started a new team with a quick speech. And in that speech I made the mistake of assuming all responsibility for the failure of the team.

I thought I was a softening the risk and encouraging them to try new things, but it had the opposite effect. I was actually taking away responsibility. It limited everyone’s investment because in being responsible for failure, I also became responsible for success. So folk were afraid to try new things and some had to be cajoled and re-motivated.

Now I try and make sure everyone recognises it’s a team effort, and whilst I have responsibilities in addition to the rest of the team, we are all responsible for success or failure, and we all have a voice in ensuring that.

Opinionated

If you’re a leader, be Opinionated, show a strong direction. And initially it doesn’t even have to be strategic. After all, you won’t know the domain on your first day.

So be opinionated about what you want most from the team. Make green builds a mantra, and dress up as a dinosaur to enforce it if you have to. Make everyone care about code consistency. Make everyone care about the quality of each other’s code.

And give them space for improvement.

And then provide as clear a path as you can. Requirements and strategy are always muddy and subject to change, so find waypoints and keep the team focused on them, knowing that you’re working on what the next waypoints are, and are available to anyone who asks.

Be a team player

Never ask your team to do something you wouldn’t do. If they have to stay in late, try to be there. If you want them talking to other teams, and visiting other countries, be with them to introduce them, and bootstrap those relationships.

Structure

Every team, every architecture, and every sprint needs a structure. A scaffold to support the work. Understand what those structures are and align them where you can. After all, the structure of a team is reflected in the structure of the code.

Make sure everyone understands the structures and why they exist the way they do. Understanding the justification means they have a context to suggest improvement, and hopefully won’t retread old ground unless the context changes.

Cohesion

Teams thrive or fail in their social interaction. As a lead, your job is to ensure the social and personal wellbeing of the team so they are as effective as they can be.

You don’t have to get drunk every night, but regular social pulses, whether a team lunch or a morning together away from the office, help to reset everyone’s view of each other and understand some of what’s going on under the surface that helps everyone relate to each other, even the shy, quiet one.

Cloud thinking : efficiency as a requirement

In the old world, you bought as big a machine as you could afford, and threw some code at it. If it could fit in memory and the disk I/O wasn’t a bottleneck, everything was golden.

In the cloud, however, CPU cycles and disk storage cost real money. Optimisation is key, so long as it’s not premature. Monitor it.

In cloud thinking, it’s less about the O(N), it’s relatively easy to scale to the input, as long as you’re not exponential. In the cloud, it’s about O($) – how well does your code scale to the amount of money you throw at your servers (or inversely, what’s the code increase per user).

Fixed costs are vanishingly small in the cloud, but incremental costs can change quickly, depending on your base platform. Not the provider, as costs between them are racing to the bottom, but the platform of your architecture.

Quite simply, the more control you ask for, the more you pay in time, and the bigger the ramp-up steps. Get metal, and you’ll pay for everything you don’t use, get a VM and you can scale quicker to match demand, get a container, get an Electric Beanstalk or an Azure website and give up the OS, get a Lambda or a Function.

I can’t recommend to you how much you should abstract. I don’t know how big your ops team are, or how much computation you need to do for each user. I suspect you might not know either. Stop optimising for things you don’t care about. Optimise for user experience and optimise for cost per user, and measure everything.

ScotSoft2016 Developer’s Conference

Normally after attending a conference, I will give a review of the talks, the interesting topics and the event itself. Unfortunately I don’t feel I can do that for ScotSoft2016. Despite being billed as a “Developer conference”, it felt like a technical event for non-developers. Enough of an overview to start to explore, but not quite enough to satisfy technical appetites. There were some good talks, but it didn’t feel like a Developer’s conference.

That said however, I did enjoy the keynote speakers, Sam Ramji of CloudFoundry and Troy Hunt of Have I Been Pwned. And there was some great advice from Asko Seeba about how to avoid writing next year’s unmaintainable legacy code by picking the right frameworks and technologies. I’m also told I missed a great pre-Halloween scare from 7Elements’ David Stubley about how insecure your web application is (although I wasn’t sure if he was wearing a hoodie and writing green text).

There was some useful information, and despite being a long day, it never felt like it. I can’t fault the venue, or the expo, and the speakers were all practiced and delivered their information well, but only a couple really hit the mark, sparking off ideas for me to go and explore.

I heard good things about the Global Forum and evening events in the conference. ScotlandIS is certainly creating the right framework for a good conference, so I’ll definitely keep it on my radar for next year and hope they figure out exactly who their audience are..

How to grok a new domain

One of the under appreciated aspects of software development is the number of different domains many of us work in over our careers, especially those working in consultancy. Software, generally, is straightforward, especially for the majority writing text boxes over databases. Not necessarily easy, but if you’re able to understand logical thought, and decomposition, picking up new languages and technologies is simply a matter of time.

The challenge is when things aren’t logical. When you have to use languages designed for humans, rather than machines, and when you have to understand processes that aren’t necessarily logical, or decomposed, and turn them into something a machine can understand.

Understanding the domain

The followers of domain driven design, and anyone who values use cases or user stories, will tell you that the first thing you have to understand is the user. What are they trying to do, and what nouns and verbs do they use to describe it?

These are the words you need to use. Whatever the system does, it should use those words to describe its state and to reflect that state back to the user.

Understanding the process

Software always models processes. Without understanding the processes, the software will model the wrong workflow, leading to a frustrating user experience. The real skill in learning these processes is understanding which are immutable and which are open to modification.

Once you start digging in, you’ll start to hear phrases like “we’ve always done it this way” or “we know that’s a bit clunky” or “here’s the workaround” which are big hints that there’s something to be improved.

Understanding the motivation

Key to understanding a new domain is understanding why. Why are people doing what they are doing – what is their goal? Why does the current software or process work the way it does? Why are you being asked to change it – what can you do to make things better?

It’s the most important question you can ask, and also the one most likely to be forgotten. Finding the right motivation for the software to exist is the key difference between successful and unsuccessful projects. One of the core tenets of agile is to keep checking that the software is meeting the needs of the users, gathering feedback and responding to it.

The logic of the illogical

For those of you that have never tried to turn the chaos of human language and rules into a logical digital narrative, I’d recommend listening to this explanation of timezones, and asking yourself how you’d go about learning all the rules and exceptions you’d need to be able to write this yourself.

Lean Coffee Retrospectives

In the comments to the previous Everyone Has A Voice post, I was asked to expand some more on the Lean Coffee Retrospective. It’s not a new idea, but it’s definitely one worth sharing in the hope that it helps others.

I first encountered the Lean Coffee format at last year’s CodeCraftConf, and read about its use as a retrospective format. We’ve used Trello’s Giphy power-up to annotate the cards, to give them some life, and to make them easier to identify. We use Trello stickers for voting, so we can identify who is voting, as it’s a great way to see who’s interested in a topic but hasn’t spoken up.

We use the STOP, START, CONTINUE format to classify what we want to talk about, and recycle the single board every week, by archiving just those columns, and copying action items to the backlog.

Is this a format you’ve tried? How did it work for you?