Demo Showcase Suite – A History – Part 2

Before I go into the details of what we did during the project, I’m going to cover two areas:  my role in the project, and the lessons I learned from previous projects and what I tried to do in this project to use those lessons.

First, I was the technical architect on the project.  At a small company, that can be a blurry title, and there were times where I ranged outside of what would normally be expected of the application architect.  What it meant to me was that I focused less on what the application did, and more on how it did it.  For instance, I chose the technologies, and resolved technical problems, but there were screens in the applications that I never saw until the project was almost complete.  There may still be screens out there that I have never seen.  I know for sure I have never looked at the help file in the application.  As long as it is there, I wasn’t concerned with it.  It is there, isn’t it?

In an ideal world, the application architect is the second busiest person during the first phase of the project.  The busiest should be the Project Manager / Product Owner as they gather requirements, get customers to sign off and kick out specs.  During the first months, I spent a lot of time trying to figure out how I wanted the project to work, what technologies I was willing to work with, and which ones I couldn’t risk.  This project was all about new technologies, and we were banking a lot of our project success on technology that didn’t even exist yet, but that was due to be delivered to us by a certain date.  i.e.  The ability to run native code in Azure apps didn’t exist when we started in January, but was delivered in March. 

Once the project gets going, gets traction, the architect should be able to slowly step aside and let the developers develop, and let the testers test.  My role was to then became the problem solver.  When a problem popped up that blocked development, I stepped in, took the issue, and tried to find a solution that worked within the overall architecture.  Sometimes that was a matter of interfacing with the Azure team, sometimes that was a weekend of trying to figure out how to create Undo / Redo patterns in Entity Framework with SQL Server CE.

The theory is that by the last few releases, the architecture work is done, and I could move on to the next phase, or the next project, gradually reducing my time dedicated to the project so that when the devs are done, the next project was ready to go, and a consistent pace could be sustained throughout the project and the year.  In theory.  We’ll come back to that later.

As far as lessons go, I’d learned a lot in the last year working on those three or four other projects, and, of course, had a dozen plus years of experience on other projects.  Here were the chief thoughts on my mind when we started:

1. I wanted specs that were easy to write, easy to read, and easy to maintain.
2. I wanted to accurately track scope changes.
3. I wanted unit tests.
4. I didn’t want to get to a week from the delivery date, need to make a change, and have to regression test everything by hand
5. I wanted the team to feel the urgency of working hard and smart early in the project to avoid the death march mindset at the end.
6. I wanted to plan for change, both in scope, the composition of the development team, technology and time lines.
7. I wanted a reliable build and deployment process from the start.
8. I wanted the team to be able to provide me with feedback quickly and easily and to give both myself and the PM a heads up well in advance of a red flag issue becoming critical.  No surprises.
9. I wanted an architecture that minimized code smell, and one I could proudly show off as the best we could possibly do
10. I wanted to enrich my technical knowledge base.

Only one of these goals would I consider an architectural goal.  But all of  them tie into making the project, and the company successful.  Some of these goals we achieved, some we got close to achieving, and some I plan to work towards achieving on the next project with the lessons learned on this one.

I’ll go into each one of these in the next entry in this series.