This may seem like a cross between a circular question and a particularly awkward attempt at a Zen kaon. Actually it is intended as a serious question about product design. In many industries that we don’t work in but periodically have to interact with it seems the products are designed to meet the needs of people who work there rather than the needs of the customer. The perfect example is the financial services industry in general and home mortgages specifically.
To the humble consumer who doesn’t work in financial services it seems that the process to get a home loan is:
- Provide sufficiently detailed history and information necessary to perpetrate identify theft,
- Hope the process completes in time,
- Stress that it won’t,
- Wait an excruciatingly long time,
- Be told “just one more piece of information is necessary” or “one of the documents you provided in step 1 has expired because step 4 took too long”.
Is my product designed to meet my needs or my customers’ needs?
This process is then repeated several times. While I am probably being unfair to the financial services industry it does bring up the question: Is my product designed to meet my needs or my customers’ needs? Now the obvious answer “I’m a software engineer, my customers are software engineers so clearly yes” can’t be true all the time or this wouldn’t be a very interesting blog. Show of hands or even better leave a comment if you saw that coming.
Before you jump up and disagree that the obvious answer is always true let’s look at some counter examples. Let’s start with CRM systems as they are a current pain point. We can take as given that CRM systems are software. Most are web apps, it’s hard to believe they could be hardware or firmware. From that we can extrapolate that most of the authors of CRM systems consider themselves software engineers. So far so good, we have a software product, developed by software engineers. Now let’s see if it is designed for software engineers.
- I’ll start with the products module; does it support listing products? Yes!
- Does it support putting a price on a product? Yes!
- Does it support putting a materials cost to the product? Yes, might be useful if I ever decide to add a side of building supplies to my software product.
- Does it track remaining inventory so that I know when to order more from manufacturing? Yes, again useful for all the coffee I ship via the internet with my software.
- Does it have the concept of a product option that changes the list price, for example node locked vs floating licensing? No, you have to multiple the number of products by the license type.
- Does it have a concept of license term? No, you can sell a 6-month license by selling a product count of .5.
- What about support for SaaS concepts like start an end date for the service? No, you put that in a free text field that doesn’t affect the price.
Now before you try and tell me that these are all unusual concepts or corner cases that aren’t all that common, check how many apply to the CRM system itself? In the case of my current CRM system, all apply to the purchase and licensing of the CRM system but are not supported within the CRM system. So how exactly was the software designed to scratch the developers own itch if you can’t actually use the system to tell the system?
Now all is not gloom and doom, except perhaps in the financial services and CRM industries. Over at ASTC we design our software, VLAB, to meet the needs of software developers. Let’s look at the common tasks faces by today’s embedded software engineer:
- Running target compiled core: fully supported.
- Debugging target compiled code: supported by both the build in scriptable debugger and by remote protocols allowing use of popular industry standard debugging software.
- Automating execution in a manner compatible with desktop Agile/Continuous process support tools: Fully supported.
- Logging results for later analysis: fully supported. Providing run to run repeatability so that defects can be analyzed every time and not just once in a blue boom: fully supported.
- Customize tooling to integrate with local processes: fully extensible API available in both Python and C++.
If there are any software development tasks I haven’t covered please let me know so that I can add them to the product requirements document I was probably supposed to be writing when I started this blog.
In summary … VLAB meets my needs as an embedded software developer far better than my CRM system meets my needs as someone trying to sell software … or than the financial services industry meets my need to get a lower rate without undue stress. While I can’t help you with your finances or CRM, don’t hesitate to contact sales@vlabworks.com for help with your embedded software development.