Archive | December, 2012

Agile Development with Enterprise Data

17 Dec

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

10 Dec

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.

10 Dec

Brett W. Green's On the Contrary

William Edwards Deming was sent to Japan in the early 1950’s and propagated his ideas about quality control and production process throughout Japanese industry.

There’s a wealth of wisdom in Deming’s work, albeit much of it industrially focused, but I’m particularly fond of his “Seven Deadly Diseases” of management (with my comments):

  1. Lack of constancy of purpose
    • It’s clear that having some core concepts about what you are trying to do is helpful… simple, effective statements about what’s important to your company, what your company does, and perhaps what your department’s role is in helping to fulfill the company’s purpose.
  2. Emphasis on short-term profits
    • Encourages what Bob Lutz describes as what-can-we-get-away-with thinking.
  3. Evaluation by performance, merit rating, or annual review of performance
    • These systems reward results rather than process-improvement, which can be counter-productive, and thereby encourage workers to maintain the status quo rather than innovate… their goal is to ‘get…

View original post 294 more words

Product Ownership in an Agile Environment

4 Dec

The technology group at Fortigent is currently undergoing some reorganization around a new group of ‘product owners’ for the various software solutions and initiatives we are working on.

In software development, the product owner’s typical responsibilities revolve around setting overall direction and ensuring that all stakeholder’s needs are addressed.  This usually involves building up requirements and setting priorities between competing features and  internal design enhancements.

But product ownership in an agile environment can be different from what people are typically accustomed to. In this system, which emphasizes rapid response to change and communication, you need to set up an iterative development cycle, with robust communication between groups, and mostly get out of the way.

It’s your job, in many ways, to simply foster the right culture. In many respects, the product is collectively ‘owned’ rather than a traditional top-down dictatorial waterfall approach.

In that vein I will layout what, in my opinion, are three most important duties of the agile product owner:


Individuals and interactions over process… Customer collaboration over contract negotiation.  This is the agile manifesto.  It’s not good enough to say ‘we gave you what you asked for’ anymore. Agile development is iterative, with constant feedback loops.  You must know as early as you can when something isn’t going the right direction. You do this with demos. You do it with conversations… phone calls… meetings.

This communication is NOT uni-directional.  It’s not just stakeholders feeding their wants and needs into engineers.  Engineers feed wants, needs and ideas to stakeholders also.  The best software comes from constant communication between these groups. Get the groups together. Encourage them to talk.  Don’t say ‘I’ll talk to Dan and get back to you’.  Instead, say ‘why don’t you go ask Dan about that’ or ‘let’s call Dan over and talk about it’. The better the engineers understand the business, and the better the business understands the engineers, the better the product.


You’ve got to be able to respond to change in an agile environment and prioritization is a constant battle. You need to have a sense of what’s most important, knowing that priorities will change and change often. Don’t get too caught up in the details.  Pick something to work on next and move on.  No one will lose any sleep if you work on A and then B… when it should have been B first. Don’t over-plan… If you trying to plan out all the way to Z you are, quite literally, wasting everyone’s time.

Recognize when engineers are going down what we call a ‘rabbit hole’… taking on a purely technical change that has no business value that takes too much time. Sometimes you have to do those things and make those choices, but sometimes you’ve bitten off more than you could chew.  These are typically difficult decisions to make.  See if you can make these changes incrementally, spreading them over multiple iterations. Involve people in the decisions. Give the business a list and say ‘one feature needs to go’ and figure out what that is. Tell the engineers when something must be released at the end of the month and they need to cut some corners. Let them figure out what can be simplified.


This is one thing the Agile Manifesto doesn’t really address when, to me, the whole business of software development is about ideas. Finding clever solutions to difficult problems. Coming up with a new way to do things that no one thought of before. It’s about creativity. Who wants to sell the same thing three other companies are selling? The name of the game is innovation.

As important as it is to listen to your stakeholders, however, they shouldn’t design your product. Sometimes the clients don’t know what they want until you show it to them. Bring your own ideas to the table, listen to your engineers and anyone else in the room. What more could the product be above and beyond what everyone has accepted as ‘the product’? Encourage this kind of thinking in the group. Don’t bring solutions to the group, bring problems. Get feedback from your end users and read it. If one thing doesn’t work, try something else.

Above all else, don’t stand still… you’ve got to move, man!  That’s what agile is all about!