Books about software product development?
June 25, 2005 6:53 AM Subscribe
We currently develop and support a large custom software application for a single client. We're approaching a situation where we want to spin that application off into a product that we implement for many clients. Each implementation will be highly customized and, for the near future, we'll only be doing a handful of them (less than 5). Can anyone recommend any relevant reading material (books, articles) for the transition?
Specifically, we're interested in general product management and development methods, as well as how to organize the source control repository such that applying bug fixes across implementations and doing releases and so forth is as painless as possible.
Specifically, we're interested in general product management and development methods, as well as how to organize the source control repository such that applying bug fixes across implementations and doing releases and so forth is as painless as possible.
Can't recommend any books, but from experience, one of the core issues you'll have to deal with is deciding what mods get to be merged into the main trunk so that all can use it, and what mods should stay as custom changes for clients, and then reconciling those differences. In the long run we found it easier to avoid making custom mods for clients by making the application customisable in it's own right. Two simple examples: allowing customer to change the names of any field on any form to suite their needs (basic i8ln strategy can do this) and allowing the customer to create custom fields that are dynamically included in forms so that if they have extra data they want to include with transactions then you don't have to mess around with customizations but can let them do it themselves, and even recycle templates across pages).
Changes like that ease the burden of the dev team, while giving more power to the client to customize things without having to increase their costs, and if you do it well enough, your application may have the abstractness required to be used in more fields than it was originaly intended for.
You might argue that in cases like that you're going to lose out on the revenue of customizations, but I can assure you that most often there will still be customizations required, but often the requests customers will have will be features that fall into the first category where they might benefit all customers (and your product as a whole).
A few more things you're going to have to take into consideration: possibilty of variation in deployment environments and deployment setups, since you guys might have done it all yourself for one client, but it might be too much of a burden to do it yourself for five clients (or even if you do it yourself as a money generating service, still better to come up with flexible automation solutions so that you can a) bill each client a little less b) save lots of time so that it takes less work to make more money). More things? Allowing flexibility in the software to let the costumer project it's own brand identity. Making the software handle more than one type of DB or OS, etc...
Hmm, I'm starting to think I might have enough there for a book of my own. I'm curious to see what others will post here.
Good luck.
posted by furtive at 8:09 AM on June 25, 2005
Changes like that ease the burden of the dev team, while giving more power to the client to customize things without having to increase their costs, and if you do it well enough, your application may have the abstractness required to be used in more fields than it was originaly intended for.
You might argue that in cases like that you're going to lose out on the revenue of customizations, but I can assure you that most often there will still be customizations required, but often the requests customers will have will be features that fall into the first category where they might benefit all customers (and your product as a whole).
A few more things you're going to have to take into consideration: possibilty of variation in deployment environments and deployment setups, since you guys might have done it all yourself for one client, but it might be too much of a burden to do it yourself for five clients (or even if you do it yourself as a money generating service, still better to come up with flexible automation solutions so that you can a) bill each client a little less b) save lots of time so that it takes less work to make more money). More things? Allowing flexibility in the software to let the costumer project it's own brand identity. Making the software handle more than one type of DB or OS, etc...
Hmm, I'm starting to think I might have enough there for a book of my own. I'm curious to see what others will post here.
Good luck.
posted by furtive at 8:09 AM on June 25, 2005
How you're going to go about this depends on a lot of things that are specific to your software. For example, where does the software live? Will you be stamping it on a CD and mailing releases to clients? Is it web-based software? If so, will they host it or will you? If you host it, will you go with an ASP-type model where you have one database and data is separated with some kind of key for each client, or will each client instance get it's own "install" with it's own set of tables?
These are huge questions (if any of them apply).
Also, furtive is right. Making the base data model flexible whenever possible is probably the single most important part of this process. For example, your software might maintain user accounts, which have First, Middle and Last names, but not Salutation. If every time you have to add something like that it means cracking open the code and burdening developers, that can cost a ton.
And you also have to deal with the fact that not every client will want every feature, so even if you did burden developers every time you had to make a change like that, you might be doing something that someone else doesn't want. This means you have to build in tons of settings to turn things on and off. However, if you build it flexible in other ways, that may not be necessary.
Building a system flexible enough to handle that, however, isn't easy... or cheap. It generally involves maintaining a lot of meta-data and building meta-systems that process that meta-data and build forms completely dynamically. That's no small task.
posted by frufry at 10:56 AM on June 25, 2005
These are huge questions (if any of them apply).
Also, furtive is right. Making the base data model flexible whenever possible is probably the single most important part of this process. For example, your software might maintain user accounts, which have First, Middle and Last names, but not Salutation. If every time you have to add something like that it means cracking open the code and burdening developers, that can cost a ton.
And you also have to deal with the fact that not every client will want every feature, so even if you did burden developers every time you had to make a change like that, you might be doing something that someone else doesn't want. This means you have to build in tons of settings to turn things on and off. However, if you build it flexible in other ways, that may not be necessary.
Building a system flexible enough to handle that, however, isn't easy... or cheap. It generally involves maintaining a lot of meta-data and building meta-systems that process that meta-data and build forms completely dynamically. That's no small task.
posted by frufry at 10:56 AM on June 25, 2005
Response by poster: To answer some of frufry's questions:
* It is primarily web-based software, with a few client-side components that some users will download from the web application and install locally.
* We will host the web application in some cases, the client will host it in others.
* Because of the level of customization of each implementation (and the variations in hosting environments), each client will get its own independent "install." I foresee maintaining a branch in source control for each implementation, such that when we make general product-level changes in the main trunk, we can merge those changes down to each implementation branch -- but this is definitely the kind of thing I'm looking for guidance on.
posted by medpt at 5:46 PM on June 26, 2005
* It is primarily web-based software, with a few client-side components that some users will download from the web application and install locally.
* We will host the web application in some cases, the client will host it in others.
* Because of the level of customization of each implementation (and the variations in hosting environments), each client will get its own independent "install." I foresee maintaining a branch in source control for each implementation, such that when we make general product-level changes in the main trunk, we can merge those changes down to each implementation branch -- but this is definitely the kind of thing I'm looking for guidance on.
posted by medpt at 5:46 PM on June 26, 2005
This thread is closed to new comments.
One answer should be in your contract - check the fine print. Legal help would be money well spent.
posted by seawallrunner at 7:47 AM on June 25, 2005