This is the Feinwerkbau P11 Piccolo Air Pistol. It costs somewhere around $1,500 and looks like it is mainly designed for people doing competition. The black barrel is what shoots the pellet and the silver barrel is the compressed air.
If you have a gun that runs on compressed air, it would be nice to know how much air you have left wouldn’t it? I’m not sure the design was fully thought through.
I don’t know the story of the gun, but I do know that you shouldn’t need to point the barrel toward your face to read a gauge.
When I see something like this I like to stop and think about whether or not I make the same mistakes in my field of software development. Poor design decisions aren’t limited to guns.
Domain Experts & Software
Mistakes in software design aren’t always as easy to spot, but often it comes down to the same thing. To design something you must have at least a basic level of domain knowledge. That doesn’t means you have to be a world famous chef in order to write a recipe webapp, but you need to make sure you at least know the basics.
If you don’t have the domain knowledge, then partner with someone who has it. I’ve been working on an application for the past year where I partnered with non-technical people who know the industry. It would have been easy to discount the value of people who can’t really contribute to writing the software, but it has been well worth it. Not only do they have the knowledge of the industry that let us create the right product, but they know the people who would be interested in buying it.
Just having a good idea and the ability to create software isn’t enough to succeed. You can significantly increase your chances by partnering with people who are in your target market who can use the product from the very beginning. If you choose carefully you can get not only their expertise in the domain, but also their network of connections–people who have the exact same problems that your product can fix.
Now some people have pointed out that a company that makes guns probably has much more domain knowledge about air powered pistols than I do. That is probably true. I have a reasonable amount of domain knowledge about guns including some classes, etc. One of the first things you learn anytime you learn anything about guns is not to point it at your face.
But this brings up an important point. Having domain knowledge and applying it are two different things.
Testing Software
When it comes to software, we have the luxury of testing. Get your code to a usable state and then let someone use it. Sometimes you’ll find that there is a disconnect between what works and what the domain experts tell you will work. This doesn’t mean you have a bad expert. They may be an expert in their field, but that doesn’t mean they are an expert at explaining it to you. Often this means that as part of the development process they will say you need to do X and then after they use it, change their mind and say you need to do Y.
This isn’t a bad thing and is a natural part of building something correctly. What you can do is try to make sure that those experiences come early and with as little pain as possible.
I was working on a project awhile back where we put most of our effort into the public facing portion of a web app. The backend was a mess through. It worked but it was very ugly. But it let us launch quickly and get some real world experience. By the time we were ready to redo the backend, the people who were using it had a lot better idea of what they needed. Many of the initial things that they wanted to change turned out to be irrelevant, but there were a bunch of other assumptions that it turned out were wrong and needed to be changed.
Domain expertise will usually get you headed in the right direction, but you don’t know if you’ve done the right thing until someone is actually using your code.
0 comments:
Post a Comment