Moving house and denormalised data

There’s a lot of abstract talk about data normalisation and having a single source of truth within your organisation for each type of data. Sometimes this goes very wrong. 

I moved house this year, and whilst I accept the extra administration that comes from each organisation needing to be updated individually (after all, why should DVLA need to know who I bank with?), I do expect each organisation to make it easy to change my address. 

And it was easy, except for my bank. Current accounts, credit cards and savings are all managed separately, the address I see online is unrelated to any of these, and I have to change my address on joint and single accounts separately. 

I don’t care what your backend system is like. My interface should be one call and you sort it out, not keep redirecting me to queue after queue. And sending me a letter to the new address telling me it’s fixed, followed by another letter dated a week later to the old address with marketing in it. 

And then, I tried to phone them about that letter, and I couldn’t pass their security questions, because my address was updated everywhere except the phone validation system. 

How easy is it for your data subjects to update their data? One call or many? Is their security tied to that data – could they lose access if a bad agent adds a new address or credit card? How confident are you that you know all the places in your user, marketing, communication and other databases that need updating? 

How can you make it easier? 

Advertisement

How to mentor

​Once you start getting experience, you’ll find other developers asking for your help. I started tutoring at university so that I could help, and reflect and improve my own knowledge. 

Mentoring isn’t about answers. It’s about learning how to find the answer. The most interesting problems we deal with are the ones that no-one knows how to do. 

When someone asks for help, help them to help themselves. You need to start asking questions to help them find their own way. 

A successful mentor makes themselves obsolete quickly, but remains available to keep asking questions. A successful mentoring process leaves the learner with autonomy and support. 

My favourite quote from my tutoring days was a pair who, after I asked them enough questions to finish the tasks, said “I like you because you make me feel smart”. 

If you’re hiring the right people, they will be smart. Make sure the mentoring and onboarding reforces that. Smart, confident people are the ones who solve problems. 

Reducing waste by delegation

Sometimes the best way to get something done is not to do it. Use your time wisely. Lean on someone else. Drop the ball. Focus on what’s important.

Don’t write your own ORM, NHibernate and Entity Framework are probably faster, more secure and less buggy than anything you could write.

Don’t manage your own servers. Let Microsoft, or Amazon, or Google, or a myriad of other providers do it for you. Let someone else monitor the patch list, recover from failures and continually roll out new hardware.

You own your dependencies, but sometimes that’s better than owning a half-baked, home-brewed alternative.

Wings of desire – future-proofing software architecture

(Note: this was originally posted on a since-archived company blog, so apologies for those who’ve read it before)

Architects are never quite sure how their buildings and common spaces are going to be used once real people move in. Just as software developers are never quite sure how their software is going to be used. Architects design openness into their designs in many ways, to allow spaces to be re-configured to a certain extend, and one important idea that they have used is leaving open areas unconstrained so that “desire lines” can form. These represent the most trodden paths, the favourite routes, across a space. Once these have settled down, months after the users have moved in, they can be formalised. Desire lines on grass are reinforced with gravel tracks. Desire lines in offices may be re-carpeted, or defined with furniture.

I’ve seen a few blogs talk about using desire lines to build web sites, using logs to determine which content was most used so that a re-design can highlight those areas or make them easier to use, and reinforce the way users are interacting with the site, but it struck me today when discussing new requirements with a client that desire lines are at the heart of many of the business processes that we model.

It is a rare occasion when a client comes to us with a fully formed idea of everything they want, so design and requirements capture is an intrinsic part of the development process, but there are many areas where the client doesn’t have an idea because no-one has tried it yet. There’s a new business process because they have a new class of user, or new laws to follow, or because the system and the business process it supports are being built together.

It’s tempting, as developers, to look for rigid rules, to find the underlying logic and find ways to make business rules concrete and algorithmic. It can also be the wrong thing to do. Have you ever had a customer or a user complain because the software does the wrong thing? When they have to work around the software to get the job done because the software is too inflexible? Not because the business process is inflexible (there’s not much we can do about red tape), but because the software enforced a business process that was incompatible with the best way to do the job.

Imagine a system where there is an approval process. There’s a screen, with a big “Approve” button on it. We know that  the requirements gathering process has identified that there are some business rules that need to be in place before approval. We know for sure that the Approver has to be a different user from the one who started the process, and in order to approve, the user has to add a comment for the audit trail. We believe there should be a time limit, but no-one knows what it should be, we know some other tasks need to be completed, but we’re not sure what. So don’t nail them down. Let the user add the comments to say that the time has elapsed. Let the audit record that the other tasks have been done. In 6 months time, the desire lines will be obvious. There will be a process. That’s when you update the screen.

We’re not mind readers or fortune tellers, so when we find ourselves looking at a problem we’re trying to nail down business rules that don’t quite make sense, or aren’t quite firm enough, maybe it’s time to step back and see if there’s a way to let users define their own desire lines where they get to decide how to get the job done, and once they understand the rules, we can always enforce them in the next version.

Is software your vocation or just a job?

When I was a tutor at university, there were three main types of students I saw in the lab: the Googlers who would search for an answer or three (in those days Experts Exchange, today Stack Overflow), mangle something together then either figure it out and simplify or give up ; the ones who cared about the craft of software development and usually just needed a nudge in the right direction with a good question or two (I remember a couple of girls telling me they liked me as a tutor because I helped them feel smart, figuring it out for themselves) ; and the ones who just wanted to do enough to get a job. 

I’ve nothing against the folks doing it just  the money, but those are the people that waterfall is for. They need structure and guidance to perform well, and that tends to happen in places where software is a component in an expensive system that has to be built by committee in a waterfall fashion. Sometimes they’ll be promoted to management and make a good job of it, sometimes they’ll be left behind by the thinkers on the team. 

The ones who think, the ones who ask questions, and who never accept “That’s the way we’ve always done things” as an answer are the ones built for modern software-as-a-solution development. The Googlers can become thinkers if they take ownership of what they wrote, or if it’s a clue for them to apply to their own code. 

If you’re not a thinker. I hope I never encounter your code outside a warning. 

Reducing waste by automation

Reducing waste is one of the key concerns of agile development, and is a defining character for Kanban, where blockages are ruthlessly identified and resolved. Timeboxing provides a low-cost means of identifying waste and a framework for tackling it, but doesn’t provide many solutions on its own.

For tasks that continually cause blockages, such as the release process, or testing, automation is a good way to eliminate the repetition, and the chance of human error. Indeed, the engineers in the audience will immediately recognise the key drivers for Continuous Deployment and Continuous Integration in the examples I’ve given.

And yet, whilst we appreciate the gains it can make, how many teams set aside specific time in their schedules for “automation” as an activity alongside “refactoring”, “upgrading dependencies” and “deleting dead code (including tests)”.

Check your backlog, and if automation, in some form, isn’t there, ask yourself why those repetitive manual steps still exist in your workflow and why they have priority over the other work you have to do.

You own your dependencies

I mentioned as part of my Your API Sucks series that I don’t want your API to be the weak point in my application. But it runs deeper than that.

Every dependency you add to your project is a codebase whose maintenance schedule you need to know, whose security vulnerabilities you and your customers are exposed to, whose existence you depend on – whether it’s a long established company or a guy who wrote 12 lines of Javascript that everyone uses. Know how you’re going to keep using it when the existing support isn’t there.

Because it’s not just one dependency, it’s dependencies all the way down.

Of course, modern software can’t be built without collaboration, without using dependencies written by others, but where you have a choice, always choose the dependency that works closest to how you’d do it yourself, just in case you have to.

Why you, yes you, should present at conferences

The best ways to learn are active, whether it’s Deliberate Practice, a proof of concept demo, or teaching someone else, anything is better than passively reading or watching a presentation. And presenting at a conference forces you to distill your learning into the pure essentials, to decide what’s important, where the roadblocks are, and tell someone else what you wish you knew when you started. 

But remember, you always have 2 audiences, those in the room, or otherwise watching live, those who are waiting to be inspired. And those following up after, the ones who were inspired and now want to learn. Those are the ones who’ll read your blog and follow the URLs so they can learn by doing.