Engineering Happiness

At IRESS over the past year or so we’ve been re-inventing ourselves. This has been happening right across the organisation, and I’ve naturally had a strong focus on the technology group. We’re not the first to do this and we won’t be the last. Some of this reinvention goes to something I think is a fundamental requirement in software engineering — engineering happiness! A lot has happened during the year, and I’m quite excited to share something very cool that I was witness to recently which has resulted in my own personal happiness.

There are a number of factors that affect engineering happiness. Many of them are personal and unique to an individual engineer, however there are some quite fundamental factors that drive a positive, upbeat engineering culture — one that ultimately helps us deliver great software to clients and users.

I polled a handful of engineers in our XPLAN Prime team to get some insight into what drives engineering happiness for them. The answers aren’t revolutionary. In this sample poll (again, potentially not surprising) they are very situational while still being broadly applicable:

• An emphasis on quality. Engineers want to be proud of their work and enjoy working on a quality codebase.
• Acceptance that producing quality takes time and effort, and should not always be traded off for “quick fixes”.
• Optimum operating rhythm. This includes the quality of the flow of work through the delivery cycle as well as how the team operates. Things to watch out for here are ensuring grooming sessions are of high quality, there’s a balance between product delivery, client delivery and technical improvement as well as quality retrospectives that produce continuous improvement.
• General technology. CI/CD software, the right hardware and operating system, good screens, great keyboards, VPN.
• An ability and recognised importance in addressing technical debt.

Technical debt

If you’re unfamiliar with the term, technical debt refers to the associated cost of additional rework caused by choosing an easy solution now rather than working on a better solution that would take longer.

This is a big topic in software engineering, impacting r many aspects of our lives (personal and business), and as a result there’s been some research on this topic (an example of which you could read here). This post by Sylvain Leroy also goes into some detail on his views of developer happiness (really starts about half way down the post).

To understand a where our technical debt issues originate at IRESS, here’s some background on what it was like here maybe a year ago.

At IRESS, we have engineered and deployed many products and solutions in a number of countries, including Australia, South Africa, the UK and Canada. Some of these products have served our clients and users for many years and have ultimately driven the successful business IRESS is today. More often than not software that’s been around for a long time contains some decay, almost always lots of technical debt along with dated practices and procedures within teams. As an engineer myself (although I rarely get the chance to practise these days) I can personally feel my internal response (rising blood pressure!) when I think about the challenges faced by our engineering teams in dealing with millions of lines of legacy code. For those living and breathing this all day you can rightly picture the blood pressure of the team, as illustrated in the (fake data) chart below:

IRESS in many cases is no different from other software engineering businesses. We have tech debt. We have aged processes. But we are reinventing and improving. My focus on engineering happiness in this post in particular comes from the team that builds and owns XPLAN Prime.

Prime

What is XPLAN Prime? “It’s a guided financial advice solution that enables the provision of objective-based, scalable advice by providing a streamlined, highly optimised and efficient advice and review process. Using the underlying power of XPLAN’s client management, calculation, portfolio and research functionality, presented in a pre-defined, engaging and simple advice journey which can be used collaboratively with clients.”

Prime is relatively new, so decay and debt is far less in Prime than what many other engineers may face in their day to day work around the world. That said:

• Prime was built with Backbone.js, with React.js added in later.
• It was started from a small POC (proof of concept) and didn’t get the re-engineering focus it should have early on.
• The team was building/using existing processes and procedures — everything from how teams were structured, to the standardised hardware and tooling to be used.
• There was, and still is, a great amount of demand for this product, which drove a very strong focus on feature delivery.
• It was built on top of XPLAN API’s with some “older/traditional” thinking behind the design and development of front-ends.

So while we have a very good product and proposition, strong demand and a capable team, the team’s engineering happiness hasn’t always been high. In fact, my non-academic survey revealed low happiness scores, as the demand for features and the work environment drove outcomes that don’t support engineering happiness!

Prime+

The good news is, as I mentioned at the start of this blog, we’re reinventing ourselves and many things have changed. What’s more, they’ve changed because the team made it happen. They jumped on an opportunity to reconsider what Prime could be, and are now working on Prime+.

The Prime+ team set a goal to build a more flexible, robust, efficient, faster and higher-quality product. There was consideration to technical aspects from an engineering perspective as well as usability and quality aspects from a user perspective.

With Prime+:

• Team members were able to access different types of hardware that better suited their working style and capabilities, e.g. MacBook/OSX rather than PC or Linux instead of Windows.
• The team chose a neat, consolidated and cohesive tech stack to eliminate some of the legacy, cross-tech issues that existed (e.g. backbone & react). They were able to improve performance of the product using some tech from AWS to monitor an end-2-end user journey and resolve based on real data rather than the more “trial & error” approach that was necessary prior.
• Using more modern practices including BFF’s to support the front end, a significant uplift to the approach to [automated] testing and a dedicated focus on UX (via a true cross functional team) from the outset.
• The CICD tooling and process was a key point of focus. This was supported by new tooling that enables code to get to production much faster and without hands.
• From a business perspective, we supported that team to change. A new physical workplace. Coaching on new ways of working. Encouragement.

The results

As a result of these changes, the engineering happiness within the team has massively changed — up to 80–90% satisfaction!

The day I sat in a showcase to see Prime+ progress, I could feel the emotion, the passion and the excitement in the team. That was a buzz for me. The scoring and testing isn’t scientific, but the impact is there and you can feel it. We can see it in the delivery outcomes. Clients will experience it in the usage and experience outcomes. Engineering happiness changes things for the better…

Of course, there’s still more to do — there always is. This is just one story and there are many more that I see and hear of at IRESS. We’re an international business, part of a rapidly changing industry and with lots of clients who need our help.

However, through re-thinking how we do our work, supported by a a dedicated team of coaches, we’re moving to true cross-functional teams globally. We’re uplifting and changing the tooling and engineering environments, and we’re working on our software and platform architectures, not for the sake of it but to make sure it helps make our work easier and more effective.

We’re pushing harder with automation, all the way from the infrastructure and networking foundation level through to software delivery and product operations. We’re defining what a “platform” looks like to support our products and ultimately our clients.

There’s a lot to do — but it’s a fun time to be at IRESS and it’s great to see the engineers leading and enjoying these changes.