Adventures while building a Silverlight Enterprise application part #29

Silverlight 4 Beta is out and it has some cool features that could help our development, but we must wait. This article is about how new versions of a platform like Silverlight impact our current and ongoing development and why sometimes you need to wait and sometimes you need to push forward.

Project status
At this point in time we are working against the clock. We have a tight schedule and we can't afford any delays whatsoever. Obviously now is not the time to switch Silverlight versions, right? Well, it's not that simple. It's not so much that we couldn't make the time. It's more that the benefits should always outweigh the costs. At this point in time, for us, it doesn't.

Pros and cons
Basically what we would benefit from right now:

• Printing support
• The new datagrid
• Improved performance

The printing support is a must have later on, but at this stage of development it just isn't that important for us. The new datagrid is a nice to have, because the one that's in there is doing the job just fine. Improved performance is nice, but right now performance is good. It will most likely drop off later, which is why I do feel we need to switch to Silverlight 4 later on.

The major downsides of switching right now are time and that four letter word 'Beta'. We'd be spending several days on first setting up a decent testing environment, doing a test upgrade, testing a lot of behavior, fixing bugs and then getting VS2010 Beta 2 rolled out to our development environments, including a TFS client. We would have these days if we could reduce the time on at least one of our functionalities needed for the first release, but there just isn't one right now.

'Beta'
I've always loved working with cutting (or should I say bleeding) edge technology and working with Microsoft beta's has improved a lot over the past years, however...
...at times you must ask yourself if it's worth the risks. In this case for example, our software is dealing with peoples paychecks. Now, I don't know about you, but a lot of people tend to get emotional when their paycheck was calculated in the wrong way, is to late, taxes were all wrong or some other mishap occurred.
One thing managers in my company don't like to hear is 'Yeah, we know about that problem that messed up thousands of paychecks. It was a problem with the beta of technology x'. Shouting would have to occur and rightfully so.

"So I shouldn't make the switch?"
It all depends. Let me start by saying I am excited about Silverlight 4 and Visual Studio 2010, but as long as they are in beta they wouldn't work for me. If you are working on code that is still a long way from release, or you are working on software you can take a little risk with, or if there is that one thing in Silverlight 4 you had been waiting on for the past year, then you should make the switch.

Be happy you're on the cutting edge.

Adventures while building a Silverlight Enterprise application part #28

Today's post is about scaling a team, especially when innovating.

Why do you need to scale?
Well, that's an obvious question. You can't do everything yourself. Even if you're one of those "can't let it go, so got to do it myself" developers, then still you might have colleagues that actually want to do some work on that cool product you're working on or use that cool technology you've introduced. However hard this can be in the beginning (and trust me, I've been there), you should start to let go and trust other developers with your code. Eventually this will pay off.

Besides letting go, what's the issue?
A simplistic approach to managing a team that needs to produce something faster, is to just throw in a couple more people. It doesn't work that way. Especially when you're doing new things and/or working on a large code base, you can't just expect a developer to walk in and start working on it.

If a new technology is involved the new developer needs to get familiar with what that technology is all about. Changes are some new tools need to be installed, some tutorials need to be followed to get a feel for the technology and then can they start and look at how this technology was applied in this particular project.

Also, if there is already a fairly large code base, then there are most likely a lot of concepts and principles that are being used in the design. A developer that has actually worked on this code from the start has gradually encountered them over time, but a developer just getting started on this code, will need to take time to get to grips with all the thought that has gone into it. For that he or she also needs someone to go over these concepts and explain how they work.

One thing I'd like to point out to the developer that gets assigned to an existing project that is on a tight schedule, stop asking "why didn't you use A instead of B?". It's irrelevant. A choice was made, most likely with a good reason and even if A was better then B, there is no time to change it. So if you're assigned to a project in progress, stop asking "why" and only ask "how".

Communication
Another issue, which is actually documented very well, is team communication. As soon as you add a person to a project, there has to be communication between the existing members and that new team member, in order to coordinate the work. That communication takes time as well. So if you're adding a person to a team, that person will spend some of it's day in communication with others and some team members will have to spend some of their day's in communication with the new team member. It really adds up as you add more team members.

One thing to do to reduce this effect is to prevent a model where everyone is communicating with every other team member. To reduce the effect, there should be someone overseeing the entire project who coordinates the team in such a way that they only need communication with either the coordinator or with a team member or two that work on adjacent parts of the project. This way you take out a lot of the pain already.

Another possibly powerful tool (if used correctly) is a stand up meeting. A concept introduced by Extreme Programming, it means you take about 5 to 15 minutes a day (depending on team size) to meat with everyone at the same time, to discuss any issues that may have occurred in the past day. This way action can be taken right away. The right people can be put together to take care of the issue.

General rules on scale
Some general tips on scaling a project:

• Don't scale to early. If a project is still half in it's design stage or is still being innovated on a lot, then wait.
• Don't scale to quickly. Once design is done and the innovation is starting to slow down, don't just through in five developers at the same time. Adding them one by one makes much more sense.
• Balance the team members. Don't just throw in all the best developers you have and think it'll work out fine. On most projects you need some people that are great at designing software and you also need developers that are going to write bulk amounts of code.
• Make sure early team members can work full time on the project. There is nothing less efficient than having to keep switching between projects, even if it's only for a question or for rework. Take the amount of time it takes to do something on an old project and multiply it by three. That's the time lost by switching.
• Don't scale up close to a deadline. What's close to a deadline depends on the projects scale. Because of the effort it takes, scaling up to close to a deadline will cause the project to go late, no matter what.

Well, that's it for today. I hope it helps you in future projects.

SilverlightShow.Net and me

It's been a bit of a crazy couple of weeks. I learned we'd have to move within the next two months, because the house we currently live in is sold. I've been quite busy with getting parts of our new application finished.
Also I received an invitation from the editors at SilverlightShow.net to write articles for them. Obviously I'm honored (and it's great for my career :-) ), so I got started right away.

On Tuesday my first article was published on SilverlightShow.net.
You can find it here.

Many thanks go out to the editors at SilverlightShow.net for their great support. A special word goes out to Svetla Stoycheva who has supported me through the process of getting this post on SilverlightShow.net.