Why software sucks - our collective lack of progress
I received an excellent question today:
Hey Runar, why is almost all new software and programs so ugly and difficult to use? Everything new from Microsoft or say Kongsberg looks like it’s made for Apple and it just looks horrible and has much less functionality than the older software’s had.. Any ideas?
An excellent question. And the answer depends on your perspective.
For me Apple-like is the closest we can get to their eternal and laudable mantra: “It just works”. However, I can see that their interface design of relentless minimalism can be limiting in an expert setting. And as Steve Jobs so aptly said: “Design is how it works”. Thus, if the UI becomes a limiting factor, the design is bad.
I do however agree with the premise. Almost all software is ugly and difficult to use. Maybe not for every use case, but every user dealing with software on a daily basis most certainly have software in their life that, for a lack of a better word, sucks. There are many good reasons for this and these reasons occupy most of my professional life.
Some of the reasons software sucks
For professional or enterprise apps, one reason is that the customer and the user seldom are the same persons. They do not share the same views in what good software looks like. For users, effectiveness and correctness without delays or superfluous data entry is paramount. For customers, the ones paying for the software, price, ease of maintenance and a good first impression matters more. And when the customer gets to decide alone, the users suffer.
In a world where developers indeed talk to users, they nevertheless often create the wrong thing for the job. They focus not on what the users need, but maybe on what the say. Developers are not designers and the teaching and methods of design science are necessary for repeated successes. A team might get lucky, but without focusing on the impact the software has on the user’s actual goal, doing a great job whatever that may be, most software will still suck in the aggregate.
Next is a toxic practice found in many software houses. Software development is hard. Really hard. And actually, it’s more than one discipline. It’s engineering, teamwork, design, complex problem solving, domain expertise to name a few.
To be a great software developer, you need many skills and some of them can only be honed by experience. You need to learn continuously and apply these new lessons in your work, iterate step by step and try to better both yourself, your team and the software you create together. But what happens when we reward the best developers by taking them off the team and making them managers, product designers or architects removed from the code? Their hard earned knowledge is gradually lost and their experience becomes less and less relevant as time goes on. And the great curse is: the further you’re removed from the code, the easier software development looks.
I said software development was hard in the previous paragraph. This is a hilarious understatement. Software is fiendishly complex. Every app, website, embedded system or expert system is complex in its own way and the complexity is different from domain to domain. And to top it off, developers are all humans, making decisions on incomplete information to solve a problem which is understood differently by everyone involved.
The skillset needed to deliver quality software has expanded significantly over the years without developers getting that much more help from tools or education. We still write our programs using plain text and the improved languages of yesteryear. Like the ice man from 1996, a developer from 1996 would understand the code we write, but not the context. And context is king. We have iPhone now. And the Cloud. And IoT. And users expecting a great user experience, privacy for their data, secure applications and at the same time crying out for smarter software predicting the user’s behaviour and needs. Thus, a complete cross-functional software team needs more specialists while working together as a unit. Proven skills are expensive to come by in a world where every company on earth is transitioning to a software-based existence. And as the number of software developers keeps increasing, the knowledge gap is widening.
Software development has borrowed its working language in part from architects and builders, but this is the worst mistake we ever did. The language itself makes everybody underestimate the difficulty in everything we do. Consider an unlucky architect, a real architect, designing a house with untested materials in a reality where the constant of gravity is not stable as on earth, but instead shifts both magnitude and direction without warning. Sounds like a complex problem to solve.
This is the reality of software development.