Software longevity – with boats

So what does the piece of software you are about to write have to do with a long-decommissioned aircraft carrier?  

Well, I’m assuming that you are working on something more complex than a marketing website that is going to get chucked away after a few months, and are – perhaps – working on a business system that is going to have many man months – and possibly many man years invested in it. In that case, the answer to the question is “more than you might think” (but yeah, it is tenuous – I really just like big ships).

The second of the Kitty-Hawk Class carriers was USS Constellation (CV-64); Her  keel was laid down in 1957, she was commissioned in 1961 and finally decommissioned in 2003, after some 42 years of service as mobile home to a crew of 6,000.

53 people died during her construction and she cost around USD 2.5 billion in 2017 dollars.

When you engage in the design and construction of an enormous undertaking like CV-64, one of the key considerations is “how long is this thing actually going to need to last?”  The benefit-of-hindsight answer to the question is often “longer than we initially expected”.

The same question needs to be applied to your software. If it needs to last 6 months, the choices you will make will be very different than if the system is going to last a decade or more. In my own career, I have worked on one system that is still in active development after 14 years and another that reached at least 20 (that I know of). They both cost multiple millions of dollars to develop and were integral to the businesses that deployed them.

For enterprise systems, like the big old ship, the truth often is that however long you think it will be used for, it will actually be used for longer in some form or another. The budget to spend hundreds of thousands (or millions) of dollars on developing a system often doesn’t come along twice. So we keep things running and we keep extending them.

The biggest challenge is predicting whether a technology chosen today is still going to be maintainable in a decade or more. In truth, there is going to be a degree of guesswork, but we can use the past to help us predict the future. The database is a really good example of something we can have a degree of surety about. If it is appropriate to your business problem, and you can store your data in a mainstream RDBMS (such as PostgreSQL, Oracle or SQL Server), we can say with close to 100% certainty that in a decade, those products will still work, will have had active maintenance, and you won’t have had to go through a version update that forced you to rewrite all your code.  

Like it or not, these products are the decades-old rocks on which enterprise systems are built. Your bank is not going to store your data in MongoDB. Well, your bank can do what it likes, but if my bank does, I’m moving my funds. Definitely use a non-relational database if you have a genuine reason, just don’t do it because (a) you are too lazy to properly model your data or (b) because it is trendy and you only work with stuff that is fun. Trendy, fun things usually hurt you when you break up with them.

The truth is that in a reductive sense, business systems exist to store and mutate organizational state. If you can figure out the storage side, that’s really half the battle won. The other half of the battle, unfortunately, is way more difficult; What do you use to write your business logic in? Of the dozens of languages and hundreds of frameworks, which do you pick?

What do I look like….? Nostradamus?

Nostradamus_portrait

Nostradamus – I don’t look like him. [Editor’s note: you do a bit actually, around the frown]

It is easier to suggest characteristics to avoid, than things to aim for. Don’t choose a framework that is at version 1 unless you are pretty sure that version 2 is likely to remain relatively backward compatible. Frameworks often need a bit of time for ideas to shake out and to end up in a somewhat final shape.  New and cool may equal expensive rework down the line. If you don’t get paid overtime, that might be you getting squeezed. And if not you, well, somebody probably is, so pay it forward and make good choices to help your fellow man (or woman).

Do you really need to pull in a third-party library to save a few lines of code, if that library comes with a dependency tree the size of an aircraft carrier? Node.JS projects undoubtedly suffer from this problem. How many of those dozens of libraries you pulled in are basically abandon-ware even by the time you type npm install? (and whist you are at it, how do really know you can trust any of this code, anyway? See previous comment about my bank).

Do you need to be web-scale? Look, if you are reading this blog, the answer is probably “no”. 99.9% of projects aren’t “web-scale”. Choose the technology that lets you solve your actual business problem, not someone else’s. If your problems are mostly synchronous, is that asynchronous platform really the best choice?

Back to big ships — In 1990, CV-64 was taken out of service for 3 years for a Service Life Extension Program (SLEP), which was intended to add an extra 15 years onto her life (for the princely sum of $800m). They could do this because she had “solid bones”. You need to make sure that your projects also have solid bones so you can squeeze extra life from them.

A “SLEP” process is also totally applicable to software. On my last big project, we made a (bad) choice in 2003 to use XUL, a Mozilla specific markup for a few of our core components, because (a) it was going to be the next great thing (guess what – it wasn’t), and (b) it was way better than HTML (that much was actually true). In the early 2010s, we engaged in a technology replacement program to rip it all out before it was dropped from Firefox.  

The important thing here was that we knew we had a bad technology choice, we knew roughly how long we could live with it and we executed a plan to move forward.  It is a good idea to periodically look at the current risk status of any technologies you are using and ensure you are in a position to mitigate any risks before they bite you. If your system is architected with reasonable separation of concerns and using open standards (i.e. don’t do what we did), you probably won’t need to replace too much in any one go.

Summary: Don’t do trendy for the sake of trendy. Anyway, I’m at 1,100 words, and I’m only allowed 800, so, blame the incoherent mess you just skim-read on editorial policy. If I’d had another 10,000 words, believe me, it would have been terrific.

UX or die

Surprisingly, there is still huge confusion around what User Experience actually is. In our age of technology and the focus on the next best, biggest thing, there’s often very little emphasis placed on making sure the user gets their say.

Whatever you’re building, someone will be using it. What do they want or need it to do? Are they good with technology, or do they struggle to turn their computer on? These are the kinds of questions and insights a User Experience (UX) expert provides. They advocate on behalf of the user.

My name is Natalie, and I am the first User Experience Guru to come on board at Media Suite.

giphy

Getting into UX in the first place

Most companies have the very beginnings of a UX culture, or they have a person who has ‘user experience’ somewhere in their job title. It’s a tricky and varied field to get into, but once you’re there, the opportunities are pretty limitless.

My UX journey started with an internship through a Callaghan Innovation Grant.

Interning…

The Callaghan Grant landed me smack in the middle of my first UX team. I was the intern to a pair of Senior UX Designers. I was nervous and excited, with drawing implements in hand and brain ready to learn. Here we focused on finding which tools worked best for our process (I can’t believe how many have now exploded across the web). I loved the supportive environment, allowing me to “fail fast” with constructive feedback.

It was also great that everyone was on-board with our not-so-secret user-focused agenda. We had a working wall which sparked great debates and helped involve everyone, from the developers to the clients. Working walls or war rooms are where you stick up anything and everything important to the project you are working on – such as designs. This open culture meant that even those up the food chain were on board with how important our users were, and had their ears open.

Starting from scratch

My next jump was like getting my training armbands taken off in the adult pool.

giphy (1)

This company was a UX wasteland, with no team or UX culture to build from. It was bare bones, but oddly liberating – although there were definitely periods where I got ‘Imposter Syndrome’. This is another super common term in my industry, essentially where you feel like your skills are not up to par and that someone will find out that you are a phoney.

giphy (2)

I was brought on with a UX contractor managing my work. Here I experienced first hand the growth, and what it meant to be a graduate, junior, and then an intermediate. My focus was on two of their main products. Both were legacy and looking to move into the web space instead. It was a chance to learn about up and coming tech, as well as jumping on the bandwagon with material design and angular.

One of the things we were aiming to achieve was to be included in discussions around new features and with potential clients – gently nudging here and there in order to put the focus back onto our users and their experiences, rather than putting out features because we thought they were needed. Interviews in order to create our personas helped a lot. It gave us something to bring to conversations, and we also brought along a developer each time so that they could finally see and talk to an end-user face to face.

giphy (3)

The journey here was all about the culture shift, having an open door policy, friendly faces and lolly drawer competitions leading to casual conversations. We started finding more out about projects by coincidence, and then later by being involved in up-front conversations around company direction.

It was also here that I got introduced to the convoluted web of Jira and confluence, discussions with subject matter experts and product owners – or in the IT world of acronyms SMEs and POs.

Communication was such a key point. I learned that instead of having long conversations over Slack or in Jira, it was much better to just have a Zoom video call. There were so many things that could be left to interpretation through messaging that I almost ended up with a personal rule: If it was going to be more than a sentence of typing to explain, I needed to make a video call or go have a chat if we were in the same office space.

Eventually we made it all the way to six team members and started to think about specialising on what each of us really loved and wanted to develop in. We learned how important team fit and culture really is. This allowed mentorship and constructive ideation, and showing a united front to convince others that users are everyone’s thing.

giphy (5)

 

At Media Suite

Now I’m on my next big adventure. At Media Suite I have different challenges. The door is wide open both for learning and helping develop a UX work style, because we already have a focus on who we develop for. I don’t need to preach – I’d be preaching to the choir – so I’m working towards a toolkit and process that I can help with while teaching what I know. Here I have so much freedom to find out what parts of UX float my boat, as well as helping with testing and asking the truly important questions – who, what, when, but most importantly, why.

Next Steps…

The next few months sees me working on two key projects, helping improve workflows and sharing the knowledge I’ve gained about our users from interviews. I’m excited to be part of the beginning journey for one of our ecosystem projects, as well as supporting and flexing my testing fingers to help with another project’s roll-out.