@dragonmantank (Twitter, app.net)
Build an app for agents to quote and issue new policies online, print ID cards and policy documents, and all the fun stuff associated with that.
* 'Fun Stuff' was subjective
We needed something that worked with our existing backend which had our raters and business logic. We didn't want to switch policy processing systems.
Turns out we had two things - a web app and an interface to the iSeries. The interface used ACORD XML, which is a standard XML schema. We could replace the web app with a new one that understood ACORD!
We went with a vendor with a pedigree in insurance. They had a Tomcat+Postgres solution, and since the magical black box talked XML, they were confident they could swap out their rating system with ours. We'd be done in 6 months.
This was good - time to market was extremely important.
We needed to bring our commercial business line online to help sell it. We had the technology (but not $6 million).
Notice how I said the Tomcat/Postgres app would be done in 6 months?
The app took much more time and budget than originally thought. How did we do a PHP app in 7 months and much less money?
Functional and Technical specifications are a must. If you don't know what you are building, how will you know how to build it? Or when it is finished?
The structured plan in which you build your software.
If you don't know how your stack works, it makes it really hard to figure out problems when things go belly up.
You do test your code right?
How do you prove your code works?
Can anyone run your tests or are they only accessible to certain people?
As the name implies, it just did functional testing. In the end it was a very expensive Selenium.
* They tried to get us to buy it, touting it as a better replacement for unit testing and Open Source toolkits. It would also allow us to run the tests instead of them.
Using unit testing and continous integration, we were able to detect test failures right away. Being able to run PHPUnit on the iSeries helped us identify and fix platform-specific bugs. Since developers could run PHPUnit and Selenium locally, we had less regressions.
Since HP Functional Testing was expensive, only certain people could run the functional tests so developers never knew when they introduced regressions or broke the build. Since it was only functional tests, it didn't find all of the bugs in the code.
How do you get code from development, to QA, to production?
This worked pretty well considering we could tag a revision in SVN that passed tests, which we could check via phpUnderControl.
tl;dr - Stuff Blew Up Regularly
Originally 6 months to production and small price tag. Ended up being way over budget and way over time. When I left, it had just barely gotten to where v1 had originally been. This was due to poor specs, poor QA, and poor development practices.
We ended up 1 month over time, but much cheaper (even when payroll was considered). It ran on existing hardware, so the software cost only ended up being Zend Server.