A Tale of Two Apps

Why Development Practices Matter

Chris Tankersley
@dragonmantank (Twitter, app.net)
http://ctankersley.com

ZendCon 2012

Who Am I?

  • PHP Developer for about 9 years
  • Worked in insurance for 4.5 years
  • I know RPG! (Not that good at it though)

What Did We Need To Do?

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 Had This... Kinda

  • Backend iSeries vendor supplied a 'solution' for our Personal Auto policies
  • Only worked for Personal Auto
  • After many years, support was dropped

What Did We Have

We needed a solution

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!

What We Decided To Do

Build Our Own!

Purchase One!

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.

Their Solution

More On Them Later

We Finally Build Our Own!

We needed to bring our commercial business line online to help sell it. We had the technology (but not $6 million).

Our Solution

Why Two Systems?

Notice how I said the Tomcat/Postgres app would be done in 6 months?

Yeah...

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?

What Was Different?

  • Proper Specifications
  • Development Lifecycle
  • Understanding Your Stack
  • Testing and QA
  • Deployment Practices

Proper Specifications

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?

There is a difference

Between This

http://www.flickr.com/photos/ell-r-brown/6050344189/sizes/l/in/photostream/

And This

http://www.flickr.com/photos/ell-r-brown/6050896474/sizes/l/in/photostream/

Development Lifecycle

The structured plan in which you build your software.

  • Waterfall
  • Spiral/Prototype
  • Agile (Scrum, Kanban, etc)

Them - Waterfall

Us - Scrum+Kanban+Agile = Something

Understanding Your Stack

If you don't know how your stack works, it makes it really hard to figure out problems when things go belly up.

Their Stack

Our Stack

Testing and QA

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?

PHPUnit

We settled on PHPUnit for unit testing. It is widely documented and we even managed to get it to run on the iSeries!

Selenium

We manually ran these tests as we hadn't worked out how to get it to run headless. Not a big deal because we had to manually run it in IE anyway.

phpUnderControl

This ran PHPUnit automatically and built our documentation.

HP Functional Testing

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.

Unit Testing Works!

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.

Deployment Practices

How do you get code from development, to QA, to production?

  • Continuous Integration Tool (Jenkins, xinc/phing)
  • Build file with manual deployment
  • Custom deployment script
  • Hope and a Prayer (Manually moving stuff)

We Went The Custom Route

  1. Tagged trunk in SVN
  2. Script checked out the build, SCP'd it to the iSeries
  3. MySQL Updates were applied by the script

This worked pretty well considering we could tag a revision in SVN that passed tests, which we could check via phpUnderControl.

They Didn't...

  1. The code on the dev server was packaged as a WAR file
  2. The SQL needed for the upgrade were put in a file
  3. A ZIP file was created from this
  4. It was sent via e-mail to us
  5. We put the WAR file in place and ran the SQL script
  6. Tomcat was restarted

tl;dr - Stuff Blew Up Regularly

Putting It All Together

Auto Quoter

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.

Artisan Quoter

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.

THE END

  • https://joind.in/talk/view/6874
  • http://ctankersley.com/talks