This was written for a course I took titled Design Thinking and Concept Development. The class was last spring, but the topic is something I am continuously rethinking. There are many different sectors in the software industry, such as operating systems, enterprise software, security, and industry specific software. One of the most visible sectors is online or web development. This part of software industry has embraced design thinking approaches such as open source software, crowdsourcing, user generated content, and online and offline complete systems. Unfortunately this is just a small portion of the software industry and the majority of the industry operates in their own way and unseen by most.
A popular model in software engineering is the waterfall model. It moves the life cycle of software through five main steps; requirements, design, implementation, verification and maintenance. Comparing this with the Life Cycle Assessment Model shows how many steps the waterfall model is lacking when designing a piece of software.
Most of the time in software lifespan is spent in development, the actual coding of the software. Before this begins, requirements are gathered from the user or customer, planning out the entire functionality of the software. These requirements are the blueprint used throughout the development process and are often held sacred. Changes are not often made to these requirements after the initial planning for many reasons. Once coding has started, a change in requirements can cause problems to the software or other requirements to be needed to be changed as well. Often, this will cost the software company more time and money that they are not willing to spend. Because of this, developers are encouraged to think of everything they want the software to do before hand and not make any changes after that. This inflexible view can lead to bloated, useless software that is not necessarily the most user friendly it could be. To test the requirements, use cases are made, visualizing what the user will need to get done, and testing that that functionality is in the software. Once all the use cases are passed, the software is considered done.
A debate among companies in the industry is what kind of company do they want to be? Software versus service. A software company creates a piece of software and then markets it as is, making profit by selling it over and over. A service company creates software that will be adapted and rewritten over and over specifically for each client, making profit through customization. Both of these types have up and down sides, a software company cannot easily change their software if it was not useful or user friendly, they need a success the first time they build it, although they spend less time and money on the development. The service companies can tailor the software very closely to what the client wants unfortunately spending a lot of man hours and money in the process.
Another common problem is the software industry is the disconnect between software developers and the customer. Often the coders of the software and the users don't communicate with the same language. This causes a need for an intermediary, or as Tim Brown talked about, T-shaped people. A T-shaped person is one with a depth of skill yet still a breath of knowledge or empathy that allows them to communicate with those in other fields. These people are not as common in the software industry as would be hoped, often causing discrepancies in software between end user and coder, such as how user friendly the software is. Often, those designing the software are more computer literate then the average user and the entire user experience is not really considered. The obvious solution to the problem is to gain user feedback on how easy it is to use the software. Unfortunately, how to do this, is not as obvious. For an online or opensource tool, its easy to get feedback right away from users, but with enterprise or industry software, it is not as simple. Having users come test the software before it is finished could be one way a company gets feedback. But how much of the functionality needs to be complete before user feedback can be tested? If you implement too little functionality then you run the risk of not having the test be useful or complete, but if you implement too much functionality then it defeats the purpose of feedback during the process as you run the risk of having to redesign too many things. An accepted model of programming is agile development. This is an iterative process of developing small amounts then getting feedback as the drive for development rather than requirements. This is a generally good approach on paper, but very difficult to put into practice for many companies.
A design thinking concept that is important to consider is crowdsourcing and co-creation. The bringing together of several different minds to solve a problem collectively. This is a very difficult thing to do in the software industry, yet useful enough to try. One way to do this is known as partner programming, where two people work together on coding. The theory being, that with someone looking over your shoulder, mistakes can be caught easier and code will be more efficient with two people thinking about it rather than one. Unfortunately, the are many downfalls to this approach, one being that it sometimes results in one person working and the other simply sitting. Often a company will not like partner programming because it results in half as much work getting done while still costing time and money for two developers. Another attempt at co-creation in software is known as code reviews. This is a process that is repeated often where someone's code is given to a group of people and they all together go over it. This allows them to check mistakes, find better more efficient ways of developing, all while keeping the entire group informed all parts of the software. In practice, these code reviews often dissolve into tedious reviews of mundane code that don't really provide anything useful.
Perhaps there is no easy way to apply design thinking to the software industry. Developing software is not a science or even an art. It is a mixture of both that is susceptible to human flaws at many parts of the process. It is common knowledge that most of a developers time will be spent fixing problems they themselves created during the writing of code. Perhaps this is inevitable and there is not a way to improve the process, or perhaps we just haven't discovered it yet and one day someone will have an innovative solution that will solve the problems of making useful software.
