Agile Development with Enterprise Data

Before coming to Fortigent, I had the fortune of working primarily on green-field or fairly new systems, all of which were autonomous within an organization. Fortigent is the first time I have had to work with a legacy system I did not build, and a database that is shared with many other applications in the enterprise. Managing database schema and developing test-first has proven to be a whole new and challenging experience in the new kind of environment.

Coming to grips with working against a shared database.

The first time I noticed that my development web.config file was pointing to a shared development database, I automatically assumed someone had inadvertently committed the file. I knew we had a sanitized database that would allow testers and product owners to preview development with a more realistic set of data, so someone had obviously pointed to one of these databases to track down some obscure bug that was hard to reproduce without more realistic data. We’ve all made that accidental commit, it happens.

The trouble was, I kept going back in time, and couldn’t find where the local database reference had been switched to point to the development database.

It had never been switched. It was the way it was.

I had to come to terms with the fact that I was in an enterprise, with many developers, and I couldn’t be the new guy that tells everyone they’re doing it wrong.

I had to learn a different way of writing my WatiN tests. I had to assume my data was in a constant state of flux and each test had to be self sufficient in getting the shared database into a state I could test. I had to accept that sometimes the build would fail, not because my code had changes, but because a completely different application team had modified the database in a way that would cause my tests to fail.

One day every test started to fail.

I was happily working from home when suddenly every test started failing. I quickly connected to my desktop at the office and noticed the same thing. What in the world just happened?

The database administrators had just tightened security on all of our database servers by removing SQL authentication. After updating the web configs to use Windows authentication, I could no longer work from home because my home computer is not on our domain.

Discovering the “local” database.

As it turned out, we do have a local database against which run many of our view model tests. Finally, I thought. I asked why we weren’t pointing our local sites to this database instead of the shared database. Like a parent who realizes that telling your child not to touch something because it is hot is not as effective as letting them feel the pain just once, a kind member of my team said, “great idea, go do that.” It turns out I couldn’t even load the login screen because the local database was basically just schema, and the existing tests that used it would simply add the data they needed and clean up after themselves.

Getting a local site to run against the local database.

Being the TDD fanatic I was, I wasn’t content with this situation. I wanted some integration tests in addition to my unit tests. I wanted to see that the view model was actually rendering the HTML correctly. I wanted to see that clicking the save button really did add a new record to the database.

And so I began several days worth of work pointing my server at the local database, and adding the metadata needed to resolve the error message. Which would be followed by another error message, and another, until one day — VOILA! — I could successfully log into the site. Whew!

The long road ahead.

Our database schema is a large, interdependent behemoth that requires the coordination of many disparate data points to generate a meaningful screen. I have managed to get enough metadata into the data base to allow me to work locally on my current feature without worrying about what is going on in the larger enterprise until I commit my changes.

For now I am happy with having made things just a tiny bit better.

Global Day of Code Retreat: A Great Way to Spend a Saturday

On Saturday I attended the second annual Global Day of Code Retreat. It was quite possibly the best developer day/conference I have attended. This is not to diminish some great conferences and code camps like MADExpo and Nova Code Camp, but this experience is different in an extremely important way.

Most conferences and code camps contain sessions aimed at keeping developers up on the latest and greatest technologies. A code retreat focuses solely on your development skills. No frameworks, no shiny new tools, its just you, a partner, your favorite IDE, test runner and some simple business rules.

For 45 minutes, you and a partner use TDD and pair programming to implement the rules for Conway’s game of life. At the end of 45 minutes, you get a 15 minute break. Oh, and you delete the code you just spent the last 45 minutes writing.

“What?” you exclaim, “Delete my code?”

Yes. Code Retreat is not about the solution, but the journey. Most of us spend day after day executing, but many of us spend very little time practicing our craft. So after the first round of programming we knew the problem better, the next 45 minutes should be a breeze.

“This time your methods may contain only four statements.”

With each 45 minute session, the facilitator presented us with different constraints. This prevented us from regurgitating the same code over and over, but more importantly it reminded me how many ways we developers have to solve the same problem.

“This time you may not use any conditional statements.”

These constraints were challenging and every green test was exhilarating.

The Global Day of Code Retreat reminded me that writing code is fun, pair programming is awesome (its been a year since I paired) and that I need to stop and take some time to practice the art of writing code, not just watching the latest TekPub video.

If you live in the D.C. area and want to spend more time practicing your craft, join the local Software Craftsmanship User Group, or better yet, facilitate your own Code Retreat.