For today I would like to discuss the important of a “Product” vs software consulting, and how that can lead to different requirements/focus. If you have worked as a consultant developing applications for a specific client, generally the most important item is usually to meet the requirements, and make sure the application works well. Although this on its own is important, when you are developing a “product” there are other factors that suddenly become important. I have found developing products to be truly an enjoyable challenge.
Here are some things that are good to keep in mind, these are general points. I will be posting more details in later entries
- Maintainability: It needs to be easy to maintain or else you will run into a nightmare long-term. Although when developing any piece of software, you want to make sure it is easy to maintain, when developing a product it’s even more crucial as support costs can kill you (you can’t always charge for support), while in the consulting business you can charge for support costs. While in the consulting business you weigh the upfront costs to the client of making the product maintenance free versus performing maintenance as needed under a support contract–the latter option is often more cost effective in a single-installation scenario.
- Architecture: When developing a product the architecture becomes much more crucial. It needs to survive the test of time, needs to be very reliable, and needs to be flexible enough to meet multiple client requirements, usually from a single code base. You no longer are building something that one entity will use, multiple clients will use it and will have different needs from the same application. Being able to achieve this goal is not as easy as it sounds. Also, make sure to keep in mind that although you usually start from one initial client need, the long-term goal is a product to be used by multiple customers. Depending on your application this might be easy or might not. Flash contains many issues that you will run into that I will discuss in other entries. Also there will most likely be some growing pains if you have never worked with such goals
- Team Consensus: Everyone on the team needs to understand that what is being worked on is a product, if the team has always been a product development team that is usually not as much of a problem, but for consultants who are transitioning into building products, usually you have to hammer in that fact a couple of times for people to get it
- Planning: Planning the development process becomes much more complex and crucial. You need a lot more thought into design, timelines, release plans, feature-set, and general product path. Not only do you need this for the developers, but you will need it for the marketing/management department and clients. Many clients want to know where the product is going before they invest heavily in a product.
- Commercializing: When developing a product you have to think of things like marketing, solid documentation, and dedicated customer support team.
- Reduce manual work: Many times when working on a consulting project, you are only interested in deploying to one server, with a single configuration, and single client. This makes the process of installation, configuration, monitoring, maintenance, and updates a minor task in comparison to the development process. When you have multiple clients with a single product though, being able to easily install, update, etc becomes important as you can easily end up taking up more time than the development process itself. This obviously depends on the complexity of the application you are working on, for us the application involves 10 or so technologies, multiple platforms and a bunch of hardware integration. For application with less complexity this is not very difficult of course, but still just as crucial.