I have worked on several projects over the last several years that were basically disaster recoveries. For one reason or another, the projects had either failed or almost failed and we had to come in and pull them out of the mire. In fact, a lot of our Solid Quality Mentors folks spend most of their time either rescuing a project or application or just a business issue with some type of data.
For starters, why do projects fail? All of the ones I have seen resulted from basically trying the old waterfall development approach where some group of folks sit around and dream up requirements and then hand them off to a development team to build. These projects usually (but not always) result in tremendous volumes of either soft or hard documents and very little code or at least little code that works to solve the business problem.
I will not bore you with tons of details on why projects get into bad shape, as there are legions of articles on the reasons. I’ll just say getting one back on track is tedious to say the least. Instead of creating a long list of the problems, let me instead focus on several things that went well and what could have been better, and then wrap up with a couple of problems and then approaches to solving them.
What Went Well
1) The Right Team
In every single project recovery effort I have seen, the team players and a top project manager were the reason the project was able to get back on track. It was critical to pick skilled folks with the right balance of work ethic and attitude. With the right people on the team, they could pick up the slack and pick up the pieces of the past and crank out application functionality that turned the client’s perception around. Then this leads to more and more features and before you know it, the client is pretty happy and the application is moving along. I have even seen this work where someone on the team had an agenda and was trying to sabotage the project.
It’s also important to allow the team to innovate and get the feature owners moving with new concepts and ideas for users to experience (called paradigm shifting when done right). Senior team members should be able to guide the team with the right amount of heads down development cranking out features to meet deadlines and tweaking the paradigms of the feature owners.
2) The Right Approach
One of the keys to any project is the right approach (sometimes called methodology) for building the solution. Check out this wiki for a good discussion:
http://en.wikipedia.org/wiki/Software_development_methodology
Now, I am not going to insist that you use Agile (http://en.wikipedia.org/wiki/Agile_software_development) or Scrum (http://en.wikipedia.org/wiki/Scrum_%28development%29) or any other approach. I have used one or the other down through the years with great success. It is vital that you adopt an approach that works for your organization and team and the particular project. The most important thing about the approach you take is that you follow it throughout the project.
We normally use either Agile or Scrum with our clients. The key things we get from them is a good process where feature tasks are short and it’s easy to show clients what is going on. Then fixing and changing directions is simple.
3) Build---> Deploy---> Test Cycle
One of the key things that are missing from many projects I have worked on is a good build / deploy / test cycle. You should notice that I placed test cycle third in the list. This is because you must automate this process early in the project if you want the project to succeed.
What does automation of this task consist of?
Build System
There are tons of build systems out there that will work. We have used a variety (such as MSBuild, TFS, Cruise Control, and Team City) over the years. It does not matter which one you use, just that you use one that automates the build process whenever your developers check in their code or at least daily.
Of course, a good source control system should underpin the build system and be rigorously used.
One of the big benefits of having a build server is the application now gets built on a build server and not on a developer’s local system. This can solve many problems because your application will be built with all of the code from other developers and you will quickly find out what assemblies (such as third-party controls or libraries) your application is missing. If they are missing on the build server that means they will probably be missing on the target systems too.
If you are using complex software such as SharePoint or BizTalk, you may need more than one build server because of dependencies in certain libraries that are incompatible with other applications, or you may have applications that can only be built on 32-bit systems. If you need multiple build severs, you can make one a central server that builds on a schedule and then pulls the output from the other servers.
Deployment Process
This is one of the most challenging elements of the entire development process and one I have spent the most time on during various projects where I was the lucky build master. It’s vitally important to automate many and if possible all of the processes to deploy your application for both testing and production. Doing this will not only save you tremendous amounts of time but also make sure the install goes correctly each time.
Luckily, Microsoft makes the deployment process pretty easy. For instance, almost all the enterprise software packages have features that you can use to automate configuration and deployment tasks. Windows PowerShell (https://docs.microsoft.com/en-us/powershell/) is also quite powerful and can be extended easily. There are also many third-party tools and software packages available either free or for little or tons of money. Just pick a solution that works for your project and environment but automate it.
4) Functional Testing Testing Testing
Let me discuss one other point on this entire process to see how the Build / Deploy cycle fits with testing. All modern software approaches have functional testing as a key requirement for the process. After all, how can you make sure something is right unless you test it?
The faster you can spin the build ( deploy process, the more quickly your testers have access to the new features and can provide you feedback on what comes next. This is absolutely key for you to have a successful application and should be a focus early on in the project.
All the major projects I have worked on in the last several years had severe problems in getting the application to a good test state after each development update. Only when this hurdle was crossed did the applications really take off.
5) User Interface Features
One of the key elements of new projects in this day and age are user interfaces. Your users are now most likely used to the glitz and glamour of cool user interfaces. They see them on many Web sites and applications they use every day and of course on TV and the movies they watch. Most folks expect your new application to have lots of that same glitz.
The XAML features in WPF and Silverlight open the door to all types of powerful features. One of my favorite features is the great fun you can have with animations and other graphical features that really make your applications look state of the art. Here is an area where you can either knock the application out of the park or bloat the application with many features that your boss or the client will think are overkill.
Let’s say your application needs to mimic real world features such as a network of computers. On one recent project we were able to create a user interface that showed all the servers in a server farm graphically, and then would animate the status of the servers when files were flowing to a server or servers or when a ping request was sent. Animation made this task quite simple. For instance, to show a turning disk drive, I use used Blend to create a circle and then a small line on the circle from the center to the edge. Then with Blend I spun a line around the circle with an animation rotating the line. Bang, a cool feature that took just minutes to implement.
Silverlight 3 introduces a new feature called PlaneProjection (http://blogs.msdn.com/jaimer/archive/2009/06/03/silverlight3-planeprojection-primer.aspx). You can use this feature to rotate an element in 3D space in any of three planes (hence the 3D moniker). The coolest feature is the element you rotate is still functional while rotated in 3D. For instance, you can have a button rotated in 3D so it’s nice and skinny, and you can still click it. Now you can build compelling user interfaces where you can divvy up the screen effectively with little wasted space.
Now let me touch on one last UI element. Let’s say you want to carry the last idea further and want a cube effect where you can spin the cube in space. Check out the Telerik RadCube (http://demos.telerik.com/silverlight/#Cube/FirstLook). This control is part of the Telerik Silverlight controls and really rocks. Just wrap one or more XAML controls in the RadCube and there you go. Then you can interact with the cube using the mouse and by using your favorite .NET code. Figure 1 shows a sample of the cube in action.
I also stumbled across this link to Microsoft Channel 9 one day: http://channel9.msdn.com/continuum/tutorials/Trigonometry/
This article covers some great tips on making a more robust interface using trigonometry with Silverlight and also using animations.
What Went Wrong
Now, let me dig into a couple problems that occur with lots of frequency in projects.
1) Performance Testing
This is an interesting area of discussion for any application development process. Performance testing is vital for any application but you must do the testing at the right points in the project. For instance, key features that are part of the core application should be prototyped and have statistics tracked early in the project. This is really prototyping to get a handle on whether this feature will actually work in the application or should be abandoned in favor for another method. When this fails to occur, problems occur over and over.
Another area of performance testing that’s critical is the proper testing of the application at various stages. It’s always important to involve everyone in the testing in order to make sure every feature is ready to test and the test areas are ready. I had a case once when I returned from a trip to a total uproar at the client. I walked in first thing in the morning and was drug into a huge meeting where everyone was screaming about the application I was working on failing the performance tests. I finally told them that I did NOT authorize any testing of the application yet and we should discount any tests until the application was ready. So what was the result of all this testing, besides the total waste of time? The test “problem” was caused by the tester who setup the tests and did not configure the test software correctly for ASP.NET. The application ran just fine when the configuration was changed.
2) Expectation Management
This is one of the hardest things to manage with a client (either internal or external). There are two ways that immediately come to mind where you can blow expectations.
- Be very very very careful about giving estimates about how long it will take to do something. I am not saying not to do this, but make sure you have a good handle on your estimate before you make it public and that you put in a good buffer.
- Also be careful about showing off cool features until you have a least looked at or prototyped them to make sure they are going to be easy to implement. For instance, some examples are incredibly complex and might take you a tremendous amount of time to create. It is easy to see a sample application that looks sort of like what your users want only to find out it’s a really long ways to the real application.
3) Dependence on Other Teams
Many large projects have multiple teams that are doing part of the work. It is very critical to make sure that all the teams are communicating and that adequate testing of all the components is taking place. This goes right back to the first points I made here that you should have a good automated build/deploy/test process in place. With this process, you should be able to do integration testing. I have seen projects where all the bits seemed to work correctly but in the end, the data was not right. It turned out that one team’s features were flawed and were returning the wrong data. Therefore, it is critical that each component of the application is not only tested to make sure it compiles and works together, but that all the data points are correct.
4) Over Engineering
One of my pet peeves is over engineering an application. We frequently walk into projects where someone before us created a very complex architecture that was great in principle but was impossible to maintain in practice. This is especially true when someone other than the author was working with the code base. I worked on a recent case where the previous developer created a deep inheritance hierarchy for a Silverlight application. This was great if all your work was in Visual Studio. However, open one of the XAML files in Blend and boom, exception time. My point is, make sure your code is logical, broken into discrete chunks, and is easy to follow. This last point usually suggests that you do not create deep complex OOP hierarchies in your UI code and probably not in the middle tier either. Complex hierarchies are hard to understand even for the developer who wrote them after a bit of time passes.
5) Top Down Mandates
One project I worked on had various parts to the application and most of these pieces were quite complex. It turns out there was one group of users who did not want a particular feature of the application to work. So they stonewalled and complained at every step to stop the application. It is critical to get user buy in or a top down mandate for an application to succeed. If users are not going to support you, then you are not going anywhere unless someone tells those users to get on board. After all, both Agile and Scrum really depend on user feedback to get the application built. If you don’t get user participation one way or another, you are likely going to run smack into a brick wall.
Conclusion
There are many areas where software (and other project types) goes astray, but usually you can boil it down to either poor or no planning or not following a good plan. All of the items in this article fit right into the plan and if you don’t go along with the plan, well then stuff happens. I’ve seen many projects fail where the team was disconnected and reacted to every changing requirement. This caused the team to churn and do lots of work but not produce results.
Ken Spencer
