I’ve been developing software professionally for over 20 years, from building Access databases, to websites, to integrating .NET, SQL Server, CRM Online and classic ASP using message queues and HTTP APIs. I’ve hired teams, I’ve delivered successful projects – and, yes, I’ve worked on a few that failed as well. I’ve designed databases, written applications, and inherited and maintained legacy projects.
I founded Ursatile not only to share the things I had learned, but also to work with companies, teams and developers and find out more about what works for them. I’ve outlined some areas below where I can offer specific experience, but I’ve worked on everything from statistical modelling to video production, so if you’re struggling with technology and software development, I’d love to chat about how I might be able to help.
It’s 2020. Every company is a software company; everyone’s talking about microservices and mobile apps and blockchain and cloud native architecture – and you’re thinking “but what is all this stuff? Why does it matter?”
It’s never been easy to figure out the right approach when it comes to technology, and everyone brings their own agenda to the table. Your developers want to work with cool, interesting technology that’ll look good on their CVs. Your CFO wants to cut costs, your support staff would be happy if you never changed anything ever again (except for fixing all the outstanding bugs, obviously). Half the team is saying you need to rewrite everything; the other half is telling you that’s too risky and expensive… so what do you do?
I can help you figure it out. Cut through the buzzwords, explain what all this stuff actually means and why it matters, and help you focus on creating software and technology that’s actually going to deliver value – not just to your customers and shareholders, but to your teams as well. Interested? Get in touch and let’s chat.
Domain Architecture Isomorphism
In 1968, Mel Conway published an article in Datamation magazine, where he shared the observation that:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
This adage became known as Conway’s Law, and it’s as true now as it was back in 1968. No matter how good your designs and noble your intentions, your organisation will end up producing systems – software, websites, services – that reflect the way your organisation communicates. Teams who sit together, chat freely and share ideas will create tightly coupled, cohesive systems; but when you need to integrate those systems with each other, you’ll probably end up with headaches. Domain architecture isomorphism, sometimes called the “Inverse Conway Manoeuvre”, starts with the outcome and works backwards: what if we designed our software first, and then restructured our teams and organisations to help us deliver that design?
Understanding domain architecture isomorphism can make a huge difference to the way your organisation delivers software – and covers everything from recruitment to deployment. I’ve presented talks about DAI at conferences all over the world, based on work I did at Spotlight between 2014 and 2018, and I’d love to help you figure out whether it might work for you.
Working with Legacy Code
Legacy code is the code everybody loves to hate. Systems that are 10, 15, 20 years old, still running in production long after the people who built them have moved on; software that’s vital to the day-to-day running of your organisation, but which you’re afraid to change in case you break something important. Does that sound familiar?
I spent 15 years running the development team at Spotlight, and watched my own projects go from being the amazing new shiny things to the dreaded legacy systems – in some cases, without changing a single detail. Legacy code isn’t a technical concern. It’s a mindset. It’s about how your organisation measures the cost and value of maintaining existing systems; about working out how to update and modify the systems that are too scary to touch; and about creating a strategy to keep the good bits, upgrade the important bits and delete the bits you don’t need.
I’ve been interviewing and hiring software developers since 2005. I’ve worked direct, I’ve worked with recruiters; I’ve hired people through word of mouth, through personal connections, through online advertising. I’ve worked with outsourced teams, contractors, freelancers, agencies… and you know what? It’s hard! Software development is a collaborative process, but finding the right people to collaborate with can be really difficult – and hiring the wrong ones can be a disaster.
If you’re struggling to hire developers, or just need some help refining your interview process, I might be able to help.