6 interesting IT facts we learned at JAX London – Day 1
Why are post-its yellow? And what does that mean for product managers? How much of the code that we write actually makes a difference? And what is the whole point of IT? We look back on six key learnings from the first day of the main JAX London conference.
1. Everything is a service
Economies are no longer driven by products, but by services. If there’s one thing that visitors can take away from the opening keynote at this year’s JAX London, it’s the impact of what it means to live and work in a post-industrial era. Your company, IT department, your dev (be that QA, ops or design) practices, even the microservices systems are built on are all services that speak to each other, says keynote speaker Jeff Sussna.
Service treats value differently. It’s not a product, it’s not like water that you pour into a glass, but an ongoing experience. And it’s the technologies behind these services that define the experience. So when a company’s help desk is mostly concerned with closing tickets, then the customer’s experience is influenced by that. And one thing we need to remember in this post-industrial era is that experience counts. Companies need to flip their approach to customer help on its head. Instead of keeping customer frustration at bay, but to actively go forth and seek feedback, positive or negative, and learning what customers need.
Meanwhile the explosion of services is increasingly complicating the user experience. When you’re car radio doesn’t work, whose fault is it? Is it Honda’s? Is it Spotify? Is it your Wi-Fi provider? Before things get simpler, they’ll be getting more complex.
2. Why post-its are yellow
Why is the post-it yellow? Because it’s a more visible colour? Because of yellow legal pads? Because it’s cheaper? No. It’s pure chance: the post-it inventor, Art Fry, needed some paper for his idea, and his local late-night paper shop only had yellow paper.
In his session on “Le Mort du Product Management” Nigel Runnels-Moss, aka SleepyFox, made the point that much of the technological innovation we know of was not formed by careful research and given a perfectly sculpted design. No project manageent process. Project management needs to transform to take advantage of innovation. The product management, market research, estimation research is often less valuable than we think.
“The first thing we should do is kill all the product managers,” says Runnels-Moss, loosely quoting Shakespeare and reminding us not to take product management as the be all and end all. Rather than spending more money perfecting our businesses, we need to “create an environment where it is safe to fail, and not failsafe.”
3. A surprising amount of programming is actually pointless
“Only 25% of a system’s features are ever needed.” It’s a tough fact to accept. And it’s one of a few that Nigel Runnels-Moss mentioned at the JAX London.
Almost two thirds (64%) of applications are never or rarely used. Meanwhile, a Department of Defense study has shown that only 2% of the code in $35.6 billion of software was used as delivered, while 75% was either never used or was cancelled prior to delivery.
— JAX London (@jaxlondon) October 13, 2015
Facts like these point us towards an interesting question. What would happen if we could focus on the third of our application that was actually being used? Would that be like tripling our budget? And would we do with all that extra cash?
4. Bad architecture means a high turnover in employees
Who wants to work on a complicated architecture, maintaining an endlessly complex nightmare that wastes a huge amount of development time? “Architectural debt is a very toxic form of technical debt,” says Alexander von Zitzewitz. But then again, writing perfect code with zero technical debt is tough.
In fact, in some companies developers are even punished for writing good code. It means spending more time on code, being more picky, and in many cases gaining a reputation for being a “code nazi”. It’s situations like these that can lead to a build up of technical architectural debt. And when good developers end up working on debt-ridden architecture, they find a different project that’s more fun. “Usually the best ones are the first to leave.”
5. It takes four months to get access to needed servers at Goldman Sachs
It’s difficult to be agile and adaptive when you can’t quickly adapt to the needs of your system. In companies like Goldman Sachs where there’s a four-month delay, you need to plan ahead, explains Vinita Rathi former Goldman Sachs vice president. Waiting until later to ask for more is difficult. So when you needed 2 servers, you apply for 4.
“More than impacting our capability to rollout to the users, I think it was a waste of infrastructure because we tried to apply for more servers, which meant we always had servers we were not using to their full capacity,” Vinita told us after her session. Goldman Sachs has since moved to solve the problem by relocating its servers to the cloud.
6. Why we do IT
Why do we do software? What is IT all for? It’s just business – at least if you ask Sacha Labourey. “99% of what you do in IT is to make more money or spend less money,” says Labourey.
And to prove his point, Labourey asks us to fast forward ten years. Car A is a self-driving car that looks really great, but kills a few people. Car B looks kind of crap, but its self-driving software is so good that there are no car crashes. Will people still buy the nicer-looking car? No, says Labourey. “Software is what truly differentiates your product.”