Building Software: Some Background
As a student and to be UX researcher, for quite some time I have wanted to start my blog. And as with almost anything, I had a lot of fear and anxiety about posting things online. I finally decided to take the leap and put my thoughts out there. I want to encourage everyone who reads this to comment with any feedback or criticism! It would be wildly helpful.
I am currently working on a project looking at the role of designers and researchers on software teams. But before I conducted any research into how things are or how they will be, I wanted to look at the past and my predispositions with the topic.
The history of software
There was a time when software was built for distribution. It was coded, burned onto disks, shipped and then sold over the counter in retail stores. What this meant for software development was that each project had a beginning and an end. Further versions or updates had to distributed in similar ways. The distribution side would often take time! And the developers had to be 100% sure before they shipped anything out.
While this is mostly conjecture, I think that this allowed for more ‘breathing’ room. Were people more content with that they had? With their needs more consistent or at least changing less slowly?
But as we all know, software isn’t like that anymore! The users are changing their minds every day. In the past year alone, I have switched from using Wunderlist to Asana to Todoist just to manage my daily list of tasks. For calendars, I have switched from sunrise to Apple Calendar (much to my dismay), and I still struggle to find the right mail app for my laptop! At my workplace, my team has switched from Skype to Zoom for video calling. We might soon by turning to slack for textual conversations as well. All this just to do your work. What this means is software had become much more dynamic.
“Software” has also added many layers of complexity. It has morphed into web services, applications (mobile, desktop and tablet) and everything that goes with it. Building software has gone from some lines of code burned on a disk to a complex dynamic system of servers, updates, plug-ins, feature lists, users, programmers, designers and business analytics.
One thing is for certain, software is no longer cut and dry and closed. It now has to work within an ecosystem of other software being used, the evolving needs of the users, backend constraints and the platform it operates in, the innovating list of startups that want to ‘disrupt’ your market.
But why are we switching like this? Why are we not content with one thing that just works for us?
The people on the technical side will tell you this is because of ease of access. We can download and try these applications so quickly! Why not try something new.
Maybe our need for novelty has finally outgrown our need for familiarity?
The designers (like me) would try and take credit — software is more easy to use than ever! We would tell you how one experience is better than the other. These applications have no learning curve!
On the business side, where there are the enticing ads on social media for new apps in the market, the blogs that write about them. Then there are the ecosystems we are plugged into. On iOS and Mac? These are the best applications for you. On Android? Well, this one is good. The list goes on and on.
Well the answer, of course, is all of them. The truth, you see, is rarely every simple.
So what about the teams?
How can I end this without a word about the teams? They are one’s dealing with the newfound complexity and every changing user needs. The more I look into Agile methodology I found that the industry has done a fantastic job to keep up with and always push the “speed” of this industry. Agile principles of responding to change over time, smaller releases, working in shorter sprints and removing distraction have worked quite well. (apologies for the oversimplification, I will go into agile principles in detail in the next few articles)
What I haven’t found is a lot of methods that helps the user’s look at the big picture. To try and understand the system as a whole. If software today is that complex, what are people using to look at the whole system? As we go faster, don’t we also become more focused? — forcing teams to look at only a few aspects of the products they are building — to focus on one thing at a time, and often not looking at the larger vision?
While these are some preliminary thoughts, over the next few weeks, I will be conducting research sessions with agile teams trying to answer some of these questions. I will be regularly posting here with my findings, thoughts and perspectives.
My name is Anish Nangia. I am a user experience designer and researcher, currently studying Human Computer Interaction at Indiana University.
I want to thank Prof. Marty Siegel, Amoli Mehta and Bhavesh Anand from their input on this article.