Almost any device today has software on it. This includes laptops, Ultrabooks, cell phones, TV sets, Set-Top-Boxes, Microwave Ovens, Cars, Medical Devices, etc. Software is created by software companies and software developers. I have seen only a few software companies who really consider all the elements of software. Most times understanding the system is the realm of the architect and is based on some unique art. Whenever I hear "art", it means that we just don't have the patterns written down yet. This is why I am publishing this post.
If your product's design or company formation does not support the following elements then you are missing on something and this eventually translates to money, either by ability to support the product, react to changes, compete with other companies, etc.
The software elements I am referring to are: UI, BL, Algorithms, Lower Interface, Upper Interface, Personalization, Security and Stability, Persistence, Performance and Accuracy, Settings, User Productivity, User Experience, Vision, Architect.
User Interface (UI) is the part of the App and R&D process which defines the graphics design and placements of interactive controls. UI can define color themes, buttons styles, fonts, and other graphical features. The UI should be defined by a professional, usually called the UI designer. The value of UI is in how it makes the users feel before they start interacting with the product.
Business Logic (BL) is the bread and butter of programmers. This is the implementation of the behavior of the application. Most times this is the reason for having software and an operating system. This is also where most requirements would change over time and where most common R&D tools are put to use. The value of BL is in the feature list. If the UI is 'what the product looks like' then the BL is 'what the product does'.
Algorithms are very hard to duplicate and therefore a good algorithm is a true value over competition. Often a huge amount of efforts are invested in improving the quality of algorithms. Algorithms are also by far better than patents. Patents are important for investors but have little to no value in the real world because: (a) the absolute majority of companies cannot enforce the legal rights of the patents because it is too expensive and time consuming, and (b) this is only relevant in countries for which the company paid to register the patent, and (c) it is only relevant after huge efforts and time spent on the patents, and (d) most often the application is finally accepted after 5 years or more, which usually means after the product is already outdated, and (e) only if nobody else could find a way to work around the patent, which usually would happen if the business justifies it. An algorithm is an IP which has its own value, can have a small investment over a period of time, and returns investment immediately. Algorithms are usually created by mathematicians and experts in the domain field of the product. A company might off-shore everything except the algorithms and still keep the product from duplication. Anything else can be duplicated by examining a product.
Lower Interface is the way the product is communicating with the lower levels. For example a driver can communicate with hardware, and an application can use system API or communicate with a driver or service. The product uses the lower level interface to communicate with libraries and engines doing work in a lower abstraction or protocol layers and with algorithms engines.
Upper Interface is the list of features provided by the product to higher level layers. For example a driver can expose a wrapper for hardware functionality, and a database engine exposes data management features.
Every product exposes features which are based on the API that it is using, this means that every product takes the Lower Interface, implements Business Logic and exposes an Upper Interface. This make the BL the difference between the features of the lower level and the features of the higher level, and is the reason for the existence of the product.
Personalization is the aspect of the product which makes the product differentiate between users. There are several reasons to tell users apart, such as Login which requires a unique password, Domain of operation such as process address space and resources, security restrictions, etc. Examples of Personalization is File ID, Window Handle, Session ID, etc. Almost every product has Personalization. Ignoring Personalization in the system design means that it is implemented without design.
Security and Stability are usually separated into two different items because security issues have been known to cost a lot of money in a single instance. Stability issues however are noticed only when it comes to database servers. Both Security and Stability cost great amounts of money in small amounts spread over long periods of time. Stability issues come from code that does not cover the un-common cases, for example user clicking the 'Next' button in a wizard while holding the Control key. Security issues come from an attempt to make the system fail, mostly in attempt to interact with the system, for example user entering 'a' as part of the age in a form. Development wise both are the same. We need to make sure that our system does what it needs to do and nothing more. If the App is supposed to go to the next page and instead is crashes and all data is lost then the App is not doing what it was supposed to do.
Persistence is where we keep the App's data. It can be on a cloud, on disk, spread on several local machines, backed-up, on Servers, and on RAM. The vast majority of Apps are created to manage data. When data is lost it is the same as saying that user's work is lost. Data can be a post in a forum and the user can retype the text, and can be game's high-score which could mean a few days of efforts. Without persistence the system does not remember anything and usability wise it means that the App does not know the user. In other words persistence is the difference between Excel and a calculator.
Performance and Accuracyis often considered as nice-to-have only, especially when features are preferred over quality. A quality product will accurately do what it is supposed to do and will do it promptly. Low quality Performance and Accuracy means that the product is less helpful for the user. Often it is the list of features that will make the user buy an App over a similar App, but it is the quality that will make the user come again and give good feedback and reviews.
Settings are a part of every product. Users may want to customize the behavior and look-and-feel of the product. All these are saved as Settings. Too many settings mean that users can’t find what they want. Too few settings mean that you expect all users to use the product in the same fashion. This is usually the case when you really know all your users. If your configuration is correct then users will appreciate very few settings. Even if users complain about the lack of ability to tweak, they will still respect the product for being robust. iPad does not let you set how you navigate the desktop, it does however let you personalize the device by setting the background.
User Productivity is why people pay for software products. Your software usually does not compete with movies, songs, art, women’s shoes, and children’s teddy bears. Mostly a software application is not something you love, it is something you use. This means that productivity is a must. Never waste user’s time. Don’t ask users questions which they cannot answer and need to think about, for example “Fatal Error…” (sounds important) “… communication down, cannot check for updates”. If you (as my App) are going to help me then don’t bug me with stupid questions. Give me answers not questions. The App works for the user, don’t expect the user to work for the App. It is OK for your employee to ask you to open the door to the office. How would you feel if your employee keeps asking you to make coffee? It is OK for your App to ask the user to connect the network cable. It is not OK for your app to ask the user to work: “cannot play the video because there is no network connection, or the file is bad, or a codec is missing, or an internal error happened”. Same goes for “Unhandled Exception: Handle is NULL” – really? That’s nice. Now what do you want me to do with this? Find you handle for you? Respect the user as you would your CEO.
User Experience is everything; people only remember the Experience. Everything else is just something they have and will soon be replaced. If you are trying to click the ‘Save’ button and accidentally hit ‘Print’ and have to wait for 5 seconds to cancel, that is a bad experience and you are going to remember it. If the App crashed during work, that’s a bad experience and you are going to remember it. If you start typing a URL and the browser remembers you and your URL - that’s a good experience. Read the forums. Everything there is based on User Experience. You want good reviews and good community drive then you better have a really good User Experience. This will dramatically reduce the cost and efforts of Marketing and Sales.
Vision is something that every good startup has. If you have a good vision then you know where you are going with the product. If you don’t have a good vision then either you are going the wrong way and will find out later, or you keep drifting around until money runs out and you have some product. Vision is based on the person who has it. You can’t learn vision and you can’t buy vision. You need to find the right person. See Borland Builder, iPhone, iPad, Facebook, Microsoft’s business model, etc.
Architect is a very nice role. Everybody wants to be the software architect, and most organizations see software architecture as a waste of money. Architects usually don’t have a budget to buy tools. Architecture is the difference between doing the same work again next year and using what you already have. Most programmers see architecture as fun because there are only few architects in the organization and it looks like you can’t go wrong because nobody will know you were wrong until next year. In real life the vast majority of Startup companies fail in the first few years because architecture is done by someone who is not fully qualified and changes in market demands really put the architecture to the test.
Follow these guidelines and you will probably have a good product.