Metadesigndriven by architectureHome
About UsIndustry FocusExpertiseWork with us Case StudiesDownloadContact
Driven by Architecture

Design in software product development


Indian software development has traditionally been all about providing services in software projects. There is no typical software project – they vary in size from very small to very large, in cost from moderately to massively costly, in complexity from very simple to highly complex, technology, domain etc. There could be a small software project of one person working for a month or a massive project with thousands of people working for years (such as computerizing the NHS). Developing 5000 web pages for a client is a simple project; whereas developing the software for the NASA rover is a very complex one indeed. There could be software projects in the medical, telecom, retail, infrastructure domains. What is true for majority of software projects is that they are for a single or finite number of clients, have a definite start and end, and are well specified once.
Historically, software product development has always been different from Projects. Traditionally, software products were small shrink wrapped pieces of software which help thousands of people do some things faster. The birth of the IBM PC (and MAC) and the MS DOS operating system brought Personal computers within reach of a huge number of people, and unleashed a need for applications to boost productivity, tools to develop software, software for project management, games etc. Philippe Kahn who came up with the revolutionary idea of shipping Turbo C for $99, resulting in sales of 100000 copies, probably invented this genre of software development. He went on to set up Borland software which had its heyday in the late eighties and nineties. The realization dawned suddenly that it might be as profitable to sell a large number of economically priced copies of a product, as to implement an incredibly big and complex software project. The eighties and nineties saw iconic products such as Wordstar, Dbase, Foxpro, Lotus 123, Word and Excel, languages such as Basic, Turbo C, Delphi etc, and games such as PACMAN and Tetris.
Characteristics Much has changed since those days, but some things about products have remained the same. A product still solves the need(s) of many people. Whether it is Google docs, or Microsoft Word or Wordstar, they all help(ed) people edit documents. A good software product could be used by millions of people in their own very individual ways, in different operating systems or environments and different hardware configurations.
Push Successful software products are often pushed, in the sense that somebody realizes that it would be cool or useful to have some software product, and that people would pay to use it, and they develop, and then sell it; a product is not usually developed based on a single user’s requirement. MicroPro International created Wordstar because they realized that when people owned PCs, they would also need software to edit files. VisiCalc was the first killer app for the personal computer; it helped people calculate their accounts, and turned the PC from a hobby to a business tool.
Evolution Bad or impractical products die out quickly, but useful software products evolve. Soon, people want it to be supported on more and more platforms, hardware, and operating systems. People start thinking “it would be nice to have these extra features too”. Soon, there are many versions floating around.
Usability A very nice technology does not necessarily make the product successful. The Usability of the software product, and its user interface often makes all the difference. Users of wordstar loved its simplicity and keyboard shortcuts, but later succumbed to the charms of the GUI based Word, Wordperfect etc. Over the years, products have become more and more bloated with more and more features. Typical Users of Microsoft Word and Excel do not use more than 20% of the features of the product.
The written word A product requires a very good help and documentation around it. Since a product is typically purchased by a client off the shelf, there is no formal training (and the price of the product itself would preclude that).
The helping hand A product requires a very good support system to succeed. Support is required to sometimes help users operate the product, and quite some times to fix problems that occur. Since a product could be used in environments and in ways never imagined by the creators, many issues arise for which short term workarounds (“For now, do not press that shortcut, instead use the menu”) should be suggested by support personnel, and fixes provided in the medium to long term. The insights gained by the support team should flow into product development and help in creating better products.
Managing complexity The need for supporting new environments, the need for introducing new features, and patches for bugs found, means that releases have to be made periodically, for different hardware, operating systems, clients sometimes, and even languages, locales etc. Each release should not miss out the patches or features that were released in a previous version. Each release requires a set of libraries, documentation files, and feature sets particular to the set of operating system, hardware etc. Maintaining this via configuration management tools is an art and a whole science by itself. The same set of tools are used to allow multiple developers to write code without treading on each others toes.
Marketing Since products are usually pushed by companies, marketing plays a very big role in the success or failure of the product. As Geoffrey Moore explains in “Crossing the chasm”, reaching the first customer is difficult; but getting the next thousand is even more difficult. Many companies falter at this hurdle. Making a product truly successful requires an ecosystem of users, VARs, user communities, support personnel, supported environments, product road map, and alliances. Because of all these peculiarities, software product development has developed in a separate way to project development. It has evolved many different approaches and techniques to deal with each of the above challenges.
What is the product? The biggest challenge is of course to build the right product. Specing out the product is tricky, doing it right can save millions of dollars in development costs, and time saved in taking the product to market in time. What are the most important factors in building a product?
The team The product likeliest to succeed would be one that is conceived by a person who is a domain specialist. This person has perhaps worked in the domain for a very long time, and has been frustrated by gaps in existing products in the market. This kind of person can come up with a really good spec. However, the pitfalls that could face such a person are – a specialist is exactly the opposite of a user, so there is the danger of missing out run of the mill features that a normal user cannot live without. The usability of the product can mean the difference between success and failure in the market, so it is essential that a usability expert contributes to the product from day one. Usability experts come in all shapes and sizes, so it is better to rope in someone who has experience in the domain, or can understand it. Usability for software is quite different from usability for industrial products, or furniture. On the other hand, these days a product is not entirely software but could be a combination of software, hardware and infrastructure. The iphone, for example is a combination of software, hardware, and connection to the wireless infrastructure.It is important to specify by prototyping quickly. A prototype gives users a very good idea of the final product, and the builder an idea of the complexity of building such a product. It is useful to organize focus groups to find out which features are used most and most attractive. These days many design firms use “unfocus” groups too. Unfocus groups gather together extreme users (who know all about the product,domain etc) and novice/unfamiliar users and find out different interesting ways in which they use the product. This often yields valuable insights into ways in which the product can be organized and features that can help in making the product really useful. The grand daddy of all design firms IDEO uses all these and other techniques to ferret out the underlying needs of a client and give them the product that they need. This is explained in this classic article in Business week http://www.ideo.com/images/uploads/thinking/publications/pdfs/power_of_design.pdf. IDEO includes diverse professionals like sociologists, psychologists, and anthropologists in the team to observe processes and understand underlying requirements. Features For a startup with limited resources, one of the most important parts in specing out a product is to decide what to leave out. The first version should come to market quickly, and should be beta tested by a large number of users. The feedback from the users should determine the subsequent shape and features of the product. For this to happen, it is essential to leave out all but those features that distinguish the product from others of the ilk.
Painting the picture Describing a software product with a view to implement it is a difficult task - the product is viewed in different ways by different stakeholders. While a business owner would like to see it described in terms of business processes, a database administrator would like to see it in terms of databases, and a programmer in terms of data structures and algorithms. The Zachman framework is a nice taxonomy for describing the methods/documents to describe a system and lays out how to describe the system in a way which can makes sense to all the proponents, and allow tracing of the requirements from specification to implementation.
Beware the pitfalls Once a product is spec’d out, it needs to be architected and designed. This is the time when the rubber meets the road. The design for a product is very different from that of a project. If a project is a house, then a product is more akin to a city. When the product succeeds, it will be constantly growing in all directions. Features will be added. It will have to be implemented in multiple platforms. If it runs as a single installation, it will have to become scalable as more and more users come online. As the pace of development becomes frenetic, more and more developers will be added to the team to add more features, fix bugs, and troubleshoot issues. Unless the product is built correctly, it will be impossible for different people to make changes independently and in parallel. Integration could become hell. Adding a feature could remove an existing feature entirely, or break it. Just building the source code into the binaries after making a change could take hours. Errors could happen randomly in production systems, and it might prove impossible to simulate this in development systems. Conflicts could develop between engineering and product management in the pace of implementing new features. A disconnect could rise between the features implemented by engineering and the features required by users. Contrary to perceptions, this kind of delay hits the most well known of companies. Windows Vista was supposed to be released in early 2005. It actually was released in January 2007. History says that it was one of the biggest disappointments in the history of Microsoft’s various operating systems. What happened to Microsoft happens in a smaller scale to many many other product development companies day by day and week by week.
Design Proper design can make a product succeed. Design (or its absence) starts much before the software design. The Design of the team that builds the software is very important. Designing a team that consists of the right mix of marketing, product management, project managers, technical people, testers and customers is critical to the products success. UI design is very important. Usability design is important. The most apt platform to develop the product should be chosen – it should depend on the hardware available to run the software, the different APIs and libraries available, the skill sets and philosophies of the team and the needs of the product. Lines of communication need to be designed so that the market can ‘pull’ the product from the engineering team, instead of the engineering team ‘pushing’ the software. Collaboration tools have to be designed for locating teams around the world, and collaborating between them. The right amount of training, breaking in, and mix of working together and apart has to be done to ensure that teams work well together. Mechanisms of telecommuting may have to be designed to ensure that people do not have to be in the same room to build a product. When they do have to get together, offices and working spaces have to be designed in such a way that it is easy to collaborate, easy to think and easy to work productively. The right mix of thinkers, coordinators, and people who get down and get things done is required.
Testing Initial and continuing testing of a product is required. The right mix of manual testers, automated testing tools, and unit tests that run nightly is required.
The ecosystem Often, it is important for a company not to do everything by itself. Instead, it should develop the right alliances with specialists in different domains, specify expectations from different players, monitor progress, and finally integrate and test outputs to ensure product creation on time. This requires a different mindset and corporate culture, one of cooperation and networking, instead of that of the lone explorer. “Can we create something better in half the time working together?” That is the question that a company needs to ask itself. Once the answer is yes, the company should deeply invest time, money, and experience in developing the relationships and working alliances, and ecosystem of cooperating companies to make this possible.

Over the past few years, there have been totally new paradigms in product development which are totally changing the way products are developed. There are some trends which, together will change the game completely. First, the emergence of the cloud will ensure that anyone can develop software quickly, and host it in an industrial strength environment. Secondly, the emergence of app stores in iphone, android, Mac, and Windows means that single individuals working alone can access markets without going through the Advertisement,VAR ecosystems. Thirdly, convergence of devices, and the growth of mobile networks as well as 3G means that many different possibilities emerge. Companies that can take advantage of these trends will ultimately win at the marketplace. And they need not necessarily be the big ones.