For the last few months, I've been rather scarce while we put the finishing touches on the new enterprise software that runs the company I work for.  I've been meaning to kick off a series of blog posts on what worked, what didn't, and why the team was able to finish a critical and complex project like this on time and under budget.  Given the abysmal project success rates in software, it's vital that we recognize contributors to success and repeat them.

Project Background

I work in the insurance industry, more specifically (and still general enough) the property and casualty niche.  On top of your normal software challenges, those of us who work in the insurance industry also get the trials and tribulations of dealing with a large amount of government regulations in addition to keeping not only your internal users happy and paying customers happy, but also keeping underwriters, auditors, and departments of insurance happy.

The company was a pretty small company when I started there, with a pretty small customer base.  Since I started, they've launched new partnerships and marketing initiatives, and their growth exploded (good thing).  However, the system that was running their business was not equipped to handle the growth well, was designed during an early phase of the company and as such didn't reflect how the business should operate, and was completely unmaintainable (long story, just take it at face value, this blog is not the daily wtf).

So the goal of the project was a complete replacement of the system that ran the enterprise.  This means enrollment/sales, underwriting, customer satisfaction, claims processing, invoicing/billing, and marketing.  A huge undertaking of critical value to the business, which is just the way I like it *puts on his superhero cape*.  The project team consisted of myself, 1 junior programmer fresh of out college, 1 midlevel developer, several SQL/.NET consultants, and 2 Web/Graphic Designers.

So let's get started, shall we?

Key 1: Know the Business

One of the things I've always enjoyed about my job is getting out in front of the other departments in a company and learning the big picture about how a company works.  Many people tend to sit in a void where only their department and their direct customers matter.  They don't understand or care how data and processes cross boundaries and flow through the business.  Not only do I care, but I make a point of being a student of business as much as I am a student of technology.  To me, IT is a service that holds up the rest of the business, and justifies its existance by ensuring that the rest of the business has the tools it needs to succeed in its tasks.  In order to provide service, you must become an expert not only in technology, but in the processes of your customers.

When I first arrived at the company, I spent the better part of several months just interviewing and sitting with people in the various departments of the company.  From the management all the way down to the employees taking the phone calls I examined how everyone was doing their job, what tasks they did most frequently, what tasks were frustrating, and what tasks were nearly impossible.  Many architects rely on the findings of business analysts or meetings with management, but I prefer to go straight to the source.  You'd be amazed what you can learn about interface design and what screens should look like by sitting with the line workers at a company.  I challenge those of you who are in control of page layout to take a layout request from a manager and another from the line workers and compare the two.  In my experience, 9 times out of 10 they look almost nothing alike.

Don't just take verbal cues either!  Look around people's workstations.  Do they have post-it notes in their workspaces?  Are they keeping data outside the application (usually Excel) because the application doesn't provide them with data in a format they need?  Ask lots of questions, really interview the end users!

Also, again I can't understate the importance (for internal IT architects) to have formal business education.  Having formal business education allows you to better serve your business customers by providing a common ground of language and knowledge of how a business works.  I can't imagine someone trying to architect a financial module for their company without knowing what "double entry accounting" was any more than you could imagine a piano repair man who couldn't play a note.

 Key 2: Know (and grow) Your Staff

The human aspect of a software project is probably the most challenging one for IT people to take on.  The challenge has two faces: The first is to get to know the abilities, limits, and aptitudes of your development team so that you can assign tasks to the people most likely able to complete them.  The second is to ensure that your developers are growing and feel challenged and appreciated. One of the most deadly things that can happen to a project is key contributors leaving before the project is complete.  Replacing or adding developers mid stream nearly always causes schedule slip because the new developers have to learn the architecture, business processes, and adapt to the environment.  Thus, ensuring that your performant developers are content is a key task to hitting your deadlines.  Also, because the later it gets in the project the harder it is to replace people, it is important that you identify dead wood developers and get them out the door and productive workers in the door as early as possible.

Key 3: Get out of the ivory tower

One tendancy I notice among architects and developers is the tendancy to live in the Ivory Tower.  Jay recently posted his thoughts on "Git R Done" coding and I'm pleased to throw my hat into that arena.  While it is great if you can follow all the latest fads like SOA, IOC, TDD, etc, at the end of the day/project, the business only cares that what you built works, and works to spec.  This is why when I gather a team of developers I give them the following instructions.

1. Be clear and consistent in naming conventions
2. Make it work
3. Clean it up
4. Refactor to patterns if necessary
5. Never, ever add gold plating

I tend to code the way the natural world works.  You never, ever see a creature in nature doing something that has no purpose.  Nor do I believe that developers should abstract, tdd, or ioc code that does not need it.  If a developer comes to me and wants a pat on the back for writing 50 tests for a class that does a few simple database lookups, they are more likely to get a pink slip than a reward for wasting time and energy on tasks that add little or no value to the project.  Developers are passionate about their craft, and this is a good thing, but it can be taken too far and turn into gold plating and abstracting for the sake of abstraction, which is a very very bad thing since it wastes their time, your money, and a future maintainer's time and money since the learning curve for the maintainer goes up when the developer does this.

This is not to say that IOC, TDD, etc are to be avoided!  Quite the contrary, they make a whole lot of sense and add a whole lot of value in the appropriate situations.  The difference between an architect and a great architect is knowing when and why to use patterns and techniques.  Additionally, in my opinion the refactoring tools (I personally use resharper) are becoming so good and powerful that my step #2 "make it work" just seems natural too me.  Back in the day, if you coded something just to make it work, refactoring was a manual process and a royal pain in the ass.  It was better to spend as much time as you needed up front to designing elegant code.  In today's world with today's tool, you can take that code that just "makes it work" and refactor it into just about any pattern you want in less than an hour.

Another reason why I push the "get r done" method is that oftentimes I find that in the process of just making it work, you learn a lot more about the process at hand.  This means that since you save your cleanup and refactoring to a later stage in the process when you are more sure about what you want the code to do.  This is one of the things that TDD does bring to the table.  It makes you think about how you want the code to look before you actually write the code, but it's not a requirement to do TDD to achieve the mentality.  This also allows you to rapid prototype the application and handle scope changes in parts of the project where the scope is plagued with uncertainty.

One of the complaints you see repeated over time in development is that schedules slip or get compressed.  By embracing a "Get R Done" mentality, at least when the schedule does slip or get compressed, you have working code, even if it isn't pretty by the ivory tower standards.  And admittedly, it's downright frustrating being preached to from the ivory tower, as most of us in the real world know.  We don't start with a clean slate, enough time, enough developers, and a free hand to make all the process and architecture decisions.  We have to make do with what we have an deliver value to the business nonetheless!