Changes in development methodology
I realize that this is probably not something advisors need to know about. However, it does impact all of you when it comes to your software and how it is delivered.
I was reading this article that talks about development methodologies and how they are changing in the big firms. Here is the short of it, the big firms are moving away from traditional development methods.
Wow, it’s about time. The traditional model used by many older development departments is called waterfall. In this model, the stakeholders sit down and define all the requirements. Then the system is architected and finally it’s built. The time from start to finish can be 18 months or more.
The problem with this model is it’s inflexibility. By the time the system is developed the requirements have changed and the software is no longer good from a business standpoint.
At Techfi we used rapid prototyping as our development methodology. In this model, the stakeholders (generally sales) would describe what they wanted and development would quickly code the prototype. The system would then be passed around round-robin fashion. Quality Assurance review, stakeholder review, code changes. We would do this cycle many times until we had the system the stakeholders wanted. The prototype became the release when everyone was satisfied.
Rapid Prototyping has it’s disadvantages as well. Generally there is no solid documentation on the system, parts of the system may unintentionally impact other parts of the system. The idea is to quickly (too quickly some would say) deliver usable software to stakeholders.
Enter Agile Development. Agile Development is a more formalized method of rapid prototyping. There are documentation requirements and longer test phases. Where Rapid Development allowed for interim releases every few days Agile will probably take a couple of weeks. Remember the traditional development model will take 18 months.
I think more software development is going to go this way. Way back when I was in college, the typical project failure rate was somewhere near 70%. Somehow we (the development community) needs to find a way to reduce this failure rate and deliver software more quickly to our clients.
I don’t want to pick on any one vendor so I will say some of these things in general terms. With underlying technology changing annually it is no longer acceptable to have a program that is only updated once every few years. However, it is very difficult for a company to release a new version every few weeks to a distributed user base. For this reason, I think we will continue to see more hosted solutions.
Bill Ramsay said,
June 14, 2007 at 1:45 pm
You are spot on Mike. We were just talking about this topic last week, as we were working on systems to provide an account transfer process as we’re in the midst of transferring all our TD Ameritrade accounts to Pershing. Your point is exactly why we don’t outsource development.
To go one step futher, how about having developers on site with a small number of key customers (or one might be enough in some situations). This would allow the developers to see opportunities that a customer or salesperson would never see. There are several problem with relying just on the customer to suggest features- mainly because they don’t see the relationships in all the data relevant to their business and customers. I would think in some cases it would get even worse when requests get translated through salespeople.
Mike Benson said,
June 14, 2007 at 2:25 pm
I think your right about things getting lost with salespeople. There are some problems with that method. In my experience salespeople tend to have niche of client types they work with and you can end up with a pretty narrow view.
Including all the salespeople is not much better, you end up with a product that is not really usable to any of your clients. Anyone remember Techfi Trader?? All things to everyone ended up being nothing to everyone because it was so complex.
I think a focused client group that can really direct a product is the best way to go. That way your key players really understand the trade-offs and can hash out a method that would work for everyone.
I also like having developers on-site. I can’t tell you how many times I have been in someones office watching a person do the same task over and over and wondered why they don’t automate the process. Developers think that way, Advisory staff generally does not.
Matt Abar said,
June 18, 2007 at 7:59 am
Techfi used agile development obviously. I’d like to clarify that we used people from both our sales and support departments in the “stakeholder” role as stand-ins for our customers. If Techfi had continued, we eventually would have added actual users to the stakeholder list. But, since we were moving so quickly, sales/support was a good substitute. Both departments had a good handle on what our prospects/clients wanted in the software.
We would make a big list in permanent marker, sorted by priority. Then the development team would sit down and put rough timeframes on each feature request. Then I would pick the actual feature list based mainly on those two pieces of information. If an important feature took too long to implement, it would be dropped and if a less-important feature was quicker, it could be moved up. These lists were hung on an easel in my office so anybody who came in could comment on them and we’d move things around based on feedback.
Occasionally we would do an emergency release if there was something that took priority. Once we did a release that was too buggy and we put everything on hold until it was cleaned up. And, right at the end, we decided we needed to do an emergency update to the AdvisorMart interface to respond to competitive pressures from StatementOne. We dropped everything and started working on that.
Actually I “left” in the middle of the project and it was never finished. As a result, we lost most of our big AdvisorMart prospects and it’s probably why Advent abandoned the broker/dealer market. But I digress…