Adventures while building a Silverlight Enterprise application part #33

In this post I want to look back and reflect. We’ve run into some issues with our project, so it seems like a good moment to learn some stuff from what we have and have not done.

Some housekeeping first

Before getting into all that though, I need to share some other stuff with you, dear reader. As you might have noticed I haven’t been posting as much as I used to. There are some reasons for that. One of them is that I’m busy building a new house (it’s almost finished) and it takes up a lot of time, getting everything organized, etc..

Another is the changes that went on in our company. I’m now heading up a team of developers and it takes more time and effort, leaving me with less time and energy to spend on writing posts.

And finally there is SilverlightShow.net. I’ve been writing some specific Silverlight articles for them. You can find all of them here. Writing for SilverlightShow means I have a more narrow format and there are some restrictions as to what I can write, but I do have a larger audience over there. This made me decide to write my specific Silverlight content for SilverlightShow and keep my other content here at Developers 42.

Something else I wanted to swing by you all is that I’m planning on enabling comment moderation. The reason being,  I’m receiving spam through the comments feature on a regular basis now. I do need to wait until I have moved into my new house and have a decent internet connection, so I can moderate any comments in a timely fashion.

Project issues

On to more important matters. Obviously I’m not going to go into detail about our internal affairs concerning the project. The goal here is to share some more generic pitfalls with you and think about what we need to do differently in the future to prevent it from happening again.

So what kind of issues are we running into? Let’s name some:

1. Longer then anticipated Time-To-Market
2. Organizational changes impacting the project
3. Framework features don’t always map to implementation features

Let’s see how these issues manifested themselves and how we deal with them.

Longer then anticipated Time-To-Market

To have a better understanding as to how this happened, it’s important to know the history of the company and the team of people involved in the project. The company I work for already exists for over forty years. Obviously in the IT business this is forever. There are people working here for over twenty years (including developers). This company went from mainframe software to client-server and now to service oriented architecture. How is this relevant?

They calculated the amount of time it takes to build a client-server application with current tools, instead of looking into the more complex service oriented architecture and the extended time lines that come with it. This made for an unfounded estimate that is far from realistic.

Another issue contributed to this. As I started working for the company, there was no one dedicated to the project and priority was given to the current product. This meant that people with intimate knowledge of the current product where unavailable at critical points during the early stages of the project. To overcome this, I should have done more investigation on getting the scope of the project right, instead of taking other peoples word for it.

Changes have been implemented to reduce the problems caused by our project running for a longer time. At first there where plans to release the entire product suite at once and migrate our customers over a short period of time after that. It has become clear that this scenario will not work and we are working on a method for customers to migrate for a part of the software, running old and new next to each other (on the same data). Also a higher priority was given to our project so we can make more progress. And finally we’ve implemented some changes in how the project is organized, which leads me to the next topic.

Organizational changes impacting the project

Now, this wasn’t all bad, but it started out with some negative impact. Unfortunately we felt the impact of the financial crisis, which resulted in the loss of several developers. Most we’re reassigned to other departments, but some had to leave the company.

Also the project was reorganized several times, before the company reorganized altogether, impacting the project once more. Now we have a structure that works well, where we have only a couple of teams working on different parts of the product suite.

The problem with reorganizing is that it requires new procedures and reinventing the way people work together in a project. You need new forms of meetings and it takes time to get used to that. It can also create situations that take time to resolve. We’re now in the process of refining the current structure. So far we feel we can go forward with how everything works now.

Framework features don’t always map to implementation features

Because of the problems at the start of the project, we now have some mismatches between framework features and implementation features. This does slow us down. So why not just fix, them? Well, we could do this, but right now priority is given to get out the first deliverable version to a small customer group. This means most of the improvements we would like to make to the framework will have to wait until after we’ve delivered this first piece.

So what should we do differently to prevent this? Well, getting a better understanding of what the project entails, before actually starting to design a framework helps. Also a better analysis on how the bulk of the functionality is going to be built should help out here. We’re seeing several cases where using the tools developed is not working as we’d hoped. I guess knowing the users of a framework is every bit as important as knowing what features to include.

So did we do things right?

Absolutely! One of the things that keeps presenting itself is the way we have designed our generic business classes and how we have abstracted our service communication from the rest. This works great. As features are added to the generic code, we keep seeing how powerful this concept really is. The same goes for how we abstracted parts of the UI. We can add features in places we couldn’t have imagined as we started building the framework.

Conclusion

Just a short recap on what to look for when starting work on a framework:

• Know the scale (both in terms of functionality as well as in data) of the software you’re building the framework for
• Know the users of your framework
• Analyze the way people need to be working in order to use your framework
• Make sure you consult different types of users before committing to a certain work method
• Make sure all the stakeholders understand what kind of effort is needed to build a decent framework

I hope you found it useful to read some of our experiences online. Please leave any comments below. They are greatly appreciated.