October 2005 - Posts
What is the most effective team size? I’ve thought about this many times over the course of my career and I’ve found that a small experienced team is best. This morning I came across an article entitled “Team Size Can Be the Key to a Successful Project” (via TargetProcess) that comes to the same conclusion. In the article QSM concludes that a team of 3–5 developers is the most likely to succeed. While adding team members always sounds like the best way to get things done faster it often leads to other problems.
What’s your ideal team size?
Jeremy Miller posted a nice long post on why the simplest thing often times isn’t all that simple. As I pointed out in my The Simplest Thing != The Easiest Thing post it isn’t always easy to implement the simplest thing. I bet there are people all over the place claiming to do XP and the simplest thing who are really just coding hack upon hack because it’s the easiest thing.
SIMPLE != EASY
SIMPLE != EASY
SIMPLE != EASY
SIMPLE != EASY
Don’t let yourself or your co-workers get away with easy when what you’re after is simple.
As I noted
in my previous post it’s important that the entire team have a good understanding of the vision for a product.
Darrell left a comment on my post with a link to
Joel’s “Design the Product Box” exercise which I think is a good thing for a team to try. It’s very easy as programmers to get heads down coding without keeping in mind the overall goals and vision for what you’re developing.
James Shore has an interesting post entitled “Earning My Pay” where he talks about some work he did with a customer in Philadelphia. Within it he details what he did to help this customer reduce their planning meeting from 2 days to 2 hours.
One thing that I’ve been having a hard time with since starting my new gig is estimates. When you combine the fact that we have a complicated domain with the fact that I don’t like to be wrong you end up with a guy who takes longer then he should to estimate stories.
In Jim’s post he talks about how he started the planning meeting with his customer by asking if everyone was ok with the fact that estimates might be wrong. He went on to say that everyone agreed that it was ok but he goes on to say “ I could tell that one of the programmers really didn't want to. “
Yeah, that was me. 
I don’t like giving estimates I’m not confident in. Jim’s advice to not ask questions about things that won’t affect an estimate as well as ensuring we limit ourselves to a set amount of time for each estimate helped tremendously. It also helped that we were estimating things that were all related to a single feature. Rather then having to switch gears to determine what we were talking about we more or less knew since we knew the 2 primary features our next iteration was focusing on.
This past week we had Jim Shore come in to help us get going with Fit. Although I learned a good bit about Fit during the week I also learned and/or was reminded of a lot of other important things.
Overall it was a very good week. I learned a lot, and got to pair with this year’s Gordon Pask Award winner
I’ve noticed lately that test driven development is now being called test driven design. I think the change is a good one since TDD is really about design, not testing. It just so happens that you end up with some good tests when you do TDD.
I think I’ve fallen victim to the test. Rather then using TDD to really drive a design I’ve been using TDD to drive parts of the design and do pretty thorough testing of that design. What this results in is a lot of unit tests which test a lot of things that you know work. This can make the tests within your system a lot more complex then they need to be. More unit tests == more code == more complexity. If you only need to write 5 tests to feel confident in your system don’t go and write 25. If you’re confident in your code you don’t always need to write another test. TDD is about design not about testing.
With that said always remember the process. Red. Green. Refactor. Don’t go and get too confident. Take small steps. If you start taking big steps and start loosing confidence back up and do the simplest thing you can to make a red bar a green one.
Don’t write new code without first writing a failing test. Once you’re bar is green, and you’re confident in your code move on. Keep your tests simple too.
One of the core principles in XP is doing the simplest thing that could possibly work. It’s important to remember that the simplest thing DOES NOT equal the easiest thing.
It’s important to combine the simplest thing that could possible work with continuous design. If you do the simplest thing and don’t also think about the overall design you can quickly end up with a mess.
Does your simplest thing make your design more complex? Does your simplest thing look like a kludge? Is your simplest thing the easiest thing? If so start thinking about what you could do that is simple but NOT easy.
On an XP project it’s easy to say “do the simplest thing”. What isn’t always easy is actually doing the simplest thing. Remember simple != easy.
In my previous post about Organizing Iterations With a Feature Focus I mention that rather then doing our iteration planning around stories we should first start with a focus on a feature.
So what is a feature? A feature is something that your customers will identify as valuable. If they can’t look at it individually and see value in it then it’s not a feature. A good way to determine if your looking at features with the right granularity is to think about what customers would think if you gave them that feature and that feature alone. Would it be valuable? Would the software be usable?
In early iterations it can be difficult to answer this question since there is a minimum number of features that your customers require. It’s at this time when a feature might be as simple as “make our software releasable”. If you can’t release your software to customers then you can’t get it in your customers hands to find out if your on the right track.
Features in early iterations might be focused more on the internal customer rather then on the real customer. You should work on the features that will direct your focus on the most important customer as soon as possible.
After you have a vision for your product you need to start building it. With so much to do and so little time it can be difficult to figure out where to start. We have hundreds of stories but which ones should we implement first?
Before trying to identify which stories to work on you need to take it up one level and think about the features within your product. What is the single most valuable feature that you can build and get in your customers hands? Don’t think about stories when planning an iteration, think about features.
Once the most valuable feature, or two, is identified then start to think about the stories that make up that feature.
Iterations should be planned around features not stories. Find the most valuable feature you can add to your software and then figure out how much of it you can get done in your next iteration. Customers want features not stories, do everything you can to give them what they want.
James Shore’s “Sense of Urgency” post states a fairly obvious but sometimes overlooked point. On XP projects customers take on much of the responsibility. They are ultimately responsible for whether or not the software is successful. They have to pick the features that we focus on. They have to deal with dates. Ultimately they’re the ones who will feel the most pain if the project isn’t a success.
As programmers I think we don’t take enough responsibility. It’s too easy for us to say, “well I know we said it was going to take X hours but it actually took X*2 hours so you’ll need to go without feature x, y, z”. We often times let ourselves off the hook too easily. We know the complexities of developing software and we use that as an excuse for not getting done the things we promised.
On an XP project I think this can be even more of an issue since in XP we focus on sustainable pace, and we drop stories that we can’t get too because of the stories that were more complicated then we thought. As programmers we need to take responsibility. As Jim Shore states, we need to care about the scope and date targets as much as the customer does.
We do test driven development (TDD), continuous integration, 3 week iterations, we plan using stories, we prioritize by business value, we try to have working software after each iteration, all and all we’re pretty agile. Or are we?
We’ve recently been noticing that we look and sound agile but we’re not really feeling Agile. We’re lacking something. But wait a second, what could we be lacking, we’re doing all the things that all those agile books talk about. Isn’t that all you need?
What we’re missing is the long term vision for our product, as well as a complete set of features that we’re targeting for our first release. What I think we’re going to be targeting could be very different then what one of the other developers on the team thinks we’re targeting. And of course what the business analysts think could be completely different as well.
It turns out that what this leads to is a team that has a hard time visualizing the overall product. A team that can’t visualize the overall product has a hard time identifying the purpose of the individual stories that are being developed. Without an overall vision the team marches on implementing stories but doesn’t really get in the “agile zone”.
A software developer needs to be able to visualize the software they’re building. They need to know the overall vision for the product. They also need to know the general features that are planned for a release. This helps them understand what they’re building and helps them make appropriate decisions at the appropriate times.
Focus on the vision for your product (or project). Identify the features that are going to provide your customers the most value. Make sure the software developers building your product understand the vision, make sure they understand what high level features will be a part of each release.
Combine this with all the other agile practices that you’ve heard so much about. Don’t let yourself slip into the trap of just identifying a bunch of stories. Make sure you have a vision. Make sure the entire team understands your vision.
Charles Young has written a nice long piece that
compares the rules within WF with the rules in the Microsoft Business Rules Engine. It’s a little long which is why I’m posting it here (aka: I didn’t read it yet and am posting this to my blog so I remember to read it when I have time).
As I mentioned in my previous post I’ve started reading up and playing with Ruby on Rails. One of the recent features which I stumbled upon is “migrations”. Migrations let you define the changes to your schema in ruby code rather then in SQL. This has the advantage of allowing the changes to be abstracted away from the actual SQL required for the change which allows for the changes to be scripted out for whatever database is currently in use. If one developer is using MySql and the other developer is using Postgres they can use the same migration files to get their databases in sync.
To read a little more about migrations check out the UnderstandingMigrations page on the Ruby on Rails wiki. While migrations in Rails are meant to be run directly against the database there is also a tool that Scott Laird created called the schema generator which uses the migrations files to create actual .sql files for various databases. The one negative of all the wonderful migration support in Rails as well as within the schema generator is that it doesn’t support all databases. Hopefully that will come in time. To get a flavor for what these migration files look like checkout the migrations for Typo.
As I was reading all the details of the migration support in Rails I started to think back to “my world” and some of the things that we’ve recently been trying to work through. The product we’re developing supports 3 databases. We’re trying to develop a process that allows us to have database changes defined in one place. We’re planning on then creating a tool that uses this data to generate scripts for each of the databases that we support (SQL Server, Oracle, Sybase). I actually downloaded Ruby + Rails to see if the migrations support in Rails could be used in our all .NET application. Well it turns out that migrations within Rails doesn’t support SQL Server or Sybase. The general idea still seems like a good one though.
Do you have a recommendation for a tool or process for managing schema changes? Does your tool or process handle defining the schame changes in a meta-language that can then be used to generate the specific SQL for various database providers? Does it handle column renames, indexes, new tables, versioning, and more?
If so let me know by leaving a comment!
Over the past couple months I’ve been drowning myself in all things WinFx. It all started when I took a new gig at a product company. We’re building a “next gen” product that if all goes well will launch in Q3 of next year. With that in mind we started looking at WinFX, more specifically Indigo, as a potential “foundation” to use in building our application. After discussing the possibility of using Indigo in our app we begun to create some prototypes. At this time I began working my way through “Programming Indigo”, as well as the slew of articles that started cropping up on MSDN. After a few weeks of reading up on most everything I could find Indigo related I felt pretty good about the basics of Indigo. I still have a long way to go before I fully “grok” the power of the layered channel model that Indigo provides but I’ve got the basics.
By this time it was PDC time. As news came pouring out of the blogosphere I tried to suck in as much as possible. I checked out the Indigo buzz and heard news of something new, Windows Workflow Foundation. At first I was pretty upset that I didn’t have a nice “code-name” for WWF but I got over it quickly as the channel 9 videos started showing yet another tool that would be a perfect fit for the some of the problems we’re trying to solve. It was time to transition from all things Indigo to all things WWF (seriously can we get a code name WWF isn’t doing it for me). I checked out the WWF articles on MSDN and ordered the Presenting Windows Workflow Foundation book from barnes and noble. A few days later the WWF book arrived which I started working my way through.
It was at about this time that I started to notice what a rut I was in. I had (and still do have) a couple side projects that I was trying to finish up. Each time I sat down to crank out the last bit of code necessary to finish the app I just looked at the screen with a wonderful blank stare. This went on for a couple days, which turned into a couple weeks. Just this past week I realized I needed a change. I needed something new, something fresh. Enter Ruby on Rails.
Over the last couple nights I’ve started working my way through Agile Web Development with Rails. The Rails community is quickly growing and based on what I’ve seen thus far it’s not surprising. Rails primary focus is on making the common scenarios that we face as developers easy. Rather then having to think about how to handle something we just look for the “Rails way”. Rather then thinking about how to lay out our project, how to map our model to our database, or how to setup all the necessary configuration we just start thinking about our application.
I’m certainly not leaving WinFx behind, just taking a brief break. When all is said and done I hope that I’ll learn some things through Rails that will help me in my platform of choice. It’s been a while since I learned a new programming language and I’m hoping doing so might help me get out of the funk I’ve been in.
Within Indigo we have several bindings to choose from. This allows us to have a single service that is exposed in several different ways for different types of clients. The current set of bindings available along with my interpretation on when and why they should be used is below:
- BasicProfile – Use this binding if you’re supporting the Web Service Interoperability (WS-I) Basic Profile 1.0.
- WsProfile – Use this binding if you need to support the various WS-* specifications such as WS-ReliableMessaging, WS-Security, and WS-AtomicTransaction. If you’re doing interoperability with other platforms that also support these WS specifications then this is the binding for you.
- WsProfileDualHttp – This binding provides all the same features as the WsProfile binding and also allows two way communication between the client and server. To allow a service to communicate with a client you need to specify a callback contract and implement that callback contract in your client.
- Intermediary – If your services need to go through a middle man for additional processing the intermediary binding is where it’s at. The intermediary binding can sit between services that are using Http, Tcp, and the named pipe transports.
- MsmqIntegration – If your services need to read messages off of a queue that is being used by a set of existing applications then the MsmqIntegration binding may be what your after. It allows a non-Indigo application to write messages to a queue that the Indigo service can then read and process.
- NetProfileTcp – If you have the benefit of running in an all Indigo world then the NetProfileTcp binding may be your best bet. Since it’s communicating over Tcp using binary encoding for messages it offers a performance boost over the bindings that communicate over Http using a Text encoding. You do need to ensure the ports that are being used to connect are open and available.
- NetProfileDualTcp – This binding is just like the NetProfileTcp binding except it offers two way communication between client and service.
- NetProfileMsmq – The NetProfileMsmq binding provides queued communication in an all Indigo world. The NetProfileMsmq binding sends binary encoded messages between client and service using MSMQ as the transport.
- NetProfileNamedPipe – If your running your client and service on the same machine, and they’re both Indigo then the NetProfileNamedPipe binding is where it’s at. It provides an efficient cross-process communication using the named pipe transport.
If your building Indigo services you might want to check out the
Microsoft Federated Identity and Access Resource Kit. It provides several samples as well as a couple documents outlining how to implement Federated Identity using Indigo (WCF) and
InfoCard.
dasBlonde is posting some good
Indigo stuff over on her blog. I’ve just added her feed to my blog roll.
Shortly after I began working on
ActiveType I came across James Shaw’s
Dozing Dogs CMS. I’ll be interested to see how
Telligent incorporates the CMS into upcoming Community Server releases.