Living in an Agile Biased World

I started today to write down some notes on the Wrox book Professional Test Driven Development with C#. I know James Bender fairly well and have met McWherter. But as I read I hit on a pet peeve of mine: arguing via bias (emotion versus logic). I thought about reviewing the book including this information, but it would not be fair, as the book should rise or fall on the merits of the material presented and not whether the authors have a strong bias towards Agile.

Let me back up a bit. I have been on the Internet since the late 80s. At that time I had to shell in via a BBS (Bulletin Board System) and use UNIX commands to navigate. Back then, arguing without a sound logical basis led to responses from the peanut gallery, especially if your faux pas was an ad hominem attack. If I go back farther in my history, I took a few logic classes (high school and college). The point is I had a background that acknowledged an argument is only as good as the reasoning behind it. A marketer would probably disagree.

One common type of logical fallacy is the straw man argument. In the straw man, you misrepresent your opponents argument and then attack it with reasoning. Since you have set up “their” position, you can easily attack it. And that is what the author’s of the book do with the Waterfall development methodology.

The Straw Man

From page 5 of the book:

The concept behind waterfall was that every software project, whose average time span was about two years, should have every phase, from inception to delivery planned from the start.

So far, the definition is mostly technically correct. But it suggests that planning is done in a bubble. Read further:

This necessitated a long period a the beginning for requirements gathering. After all the requirements were gathered, they were “thrown over the wall” to the architects. The architects took the requirements and designed the system that would be built down to the smallest detail. When they completed this task, they threw the design over the wall to developers, who built the system.

Now this is where things start to break down. Even in the worst waterfall shop I have worked in, nobody threw things over the wall. In fact, architecture is almost always treated as a collaborative process, sometimes more effectively than others. In addition, even in larger organizations that had architecture groups, I have never seen architects isolated from developers. Maybe it happens in some organizations, but years of experience show me bad architecture is far more common than the ivory tower picture presented in the book (the words ivory tower architects are used on page 6).

Other things misrepresented:

1. Waterfall testing is performed by manually running scripts (page 5) – Not since the early 80s in most shops
2. All requirements are gathered early on and cemented (page 5) – While waterfall is more strict, there is a change management process when done correctly.
3. The work must be estimated up front – This is technically correct, but in a good waterfall shop, estimates are estimates, not firm commitments

And here is the one that set me off:

Unlike waterfall, which seeks to control and constrain the realities of software development, agile methodologies embrace them.

Now this comment is just plain silly. Not only is it not supported by the text of the book, I am shocked that nobody called the author on this one. “Constrain the realities”? Really?

I was going to stop here, but chapter 2 has a comment that really kicked me in the gluteus maximum (page 24-25).

Imagine for a moment you are building a house. For most of us, a house is the most expensive thing we will ever buy. the opportunity to have a house built to your desires and specifications is something to be excited about. Imagine, though, that when you leave the architect’s office for the last time, you will not be allow to see the house’s progress or make changes to the blueprints or design until the house is completed. Imagine that the first time you get to see the house is the day you move in. How well do you think the house would reflect what you actually wanted? It may reflect what’s on the blueprints, but there’s a big difference between a drawing and a physical structure. Amazingly, this is how many companies still develop software.

I have to throw the bullshit flag on this one. While there are companies that attempt to develop in a box, without any feedback, they generally fall in the category “out of business”. Even in the strictest agile shops, we group functionality, have POCs, demos, and means of making changes to reflect changing business needs, goals and drivers. You don’t meet with the architect and then find what was done until the walkthrough. It may happen somewhere, but it does not happen often.

Okay, it sounds like I am picking on the authors, but what I am really on is the idea of misrepresenting something, whether it be a hacked conspiracy theory about aliens and 9/11 or a development methodology. Personally, I am an Agile junky to an extent, and a strong advocate of Test Driven Development (TDD), although I tend to move towards a more Behavior Driven Development (BDD) style. More on this in a bit.

Methodologies

What is waterfall?

In the waterfall methodology, you have a list of requirements you need to get completed. You also have a list of items the developers are currently working on. The full scope of the work and the current list are consolidated using a project plan, generally represented as a Gannt chart. As a particular requirement is completed, it is tested. When development is completed, the software is stabilized to eliminate bugs and released.

Okay, so what is Agile?

In the Agile methodology, you have a list of requirements you need to get completed. You also have a list of items the developers are currently working on. The full scope of the work and the current list are consolidated comparing the backlog to work done, generally represented as a burndown chart. As a particular requirement is completed, it is tested. When the development is completed, the software is stabilized to eliminate bugs and released.

Wow, they sound pretty much the same? Yes, at the high level. What are the differences?

1. In waterfall, you generally try to get the FIRST PASS of the system defined through requirements before you start work. Once this first view is agreed on, you will need an approved change request with the new requirement. In Agile, you simply add the new requirement to the stack.
2. In waterfall, you have gates at the end of a phase. This does not mean you cannot return to a previous phase and start forward again, or even send some of the group back into a previous stage. It does mean, when done correctly, that you get sign off at the end of a phase that the work is done, prior to moving full force into the next phase. In Agile, when done correctly, you iterate until you either clear all of the requirements, or (the bonus for the properly done Agile) until business states “can we release it now” and you go into stabilization.
3. In Agile, done correctly, one aspect of development (time or features) is favored. In most cases (except Feature Driven Development), the key driver is time.Time is sliced up into small chunks (generally 2 to 3 weeks) and each piece of work is completed to at least beta quality and demoed. This is artificially accomplished in most waterfall shops, as well.

The Good, the Bad and the Ugly

There is good development and bad development. This is a truism whether you are using a waterfall methodology or an Agile one. The assumption in the book, and with many other developers who have embraced Agile, is waterfall is bad and Agile is good. Take, for example, this quote on page X:

[Agile Methods] are also not about chaos or “cowboy coding”. In fact, agile methodologies require a larger degree of discipline to administer correctly.

In many shops I encounter, Agile is chosen to facilitate a few cowboys who don’t want to plan or write documentation. I am glad the discipline is mentioned here, but it is more often missing in shops that claim to be Agile. I have heard the following in Agile shops:

• Agile is about writing requirements during development – Then why are all of your TBIs (Team Backlog Items) one liners with empty task definitions.
• My tests and code are my requirements documents – This only works if you are writing the correct tests and code.
• If you have to comment, you are not doing Agile – Okay, I agree that comments in code often explain what the code does, rather than why, making them useless. And, I agree the discipline of refactoring to eliminate the comment is a great practice. Unfortunately, most of the cowboys I have encountered that dis comments fail to refactor enough to eliminate the need for a comment, even though they do not write a comment.
• We don’t need documentation with Agile – No, we let the next group guess what our intent was and have people hack our libraries in strange ways to fit their requirements, leading to new defects that could have been avoided by documenting rather than forcing an exploration operation.

So Agile does not have a lock on good practices any more than waterfall has a lock on bad practices. Agile is another paradigm, not an evolution or revolution in development. Once you have that down, you start to realize you can take either method and make good software, or you can mix and match the best of each world. You just need everyone on board. So what is good, bad and ugly?

Bad waterfall is serial in nature,with no parallelism in the pieces. Good waterfall allows for overlap, and is fully collaborative, but signs off the phases in order to ensure things are not missed. Ugly waterfall is not only serial, but extremely rigid.

Bad agile is a group of mavericks pulling code with little response back to the business until the demo. Good agile is a collaborative effort that includes coders, business and testers in the team. Ugly Agile ends up with all code written unplanned in a stream of consciousness, often ending up with an overly complex solution that simply does not work.

The important thing to remember is you need all of the following to have a successful system built:

• An understanding of what is being built before it is built. This can be up front (ala waterfall) or as work is pulled off the stack (ala Agile), but more likely you have a hybrid of the two. Even in the strongest Agile shop, the business guy who came up with the requirement probably has a good idea what it should look like and that has to be conveyed to be effective, whether it is on paper, in a meeting, on a phone call or sitting next to you (best in Agile).

The Real World

In the real world, you find the following:

• Sans a strong case, you are stuck with a set of resources. This is a budgetary constraint.
• Whether you are Agile or Waterfall, business has an idea when they want to release and it often a stake in the sand whether you piece out the work or do it all “big bang”.
• In all systems, there is change during the project. Agile, on paper, has a better method of handling this change, but waterfall has a better method of planning and documenting the change.

In the real world, I find political fiefdoms whether the shop is waterfall or Agile. Waterfall allows a fiefdom to exist through rigid sign off procedures, so the one with the sign off pen takes control. Agile allows fiefdoms to exist by avoiding all rigidness and allowing the cowboys to take control. Both are dangerous towards getting development completed.

Which is Better?

This is like asking “which is better, steak or ice cream?” The best depends on the mood and tastes of the people going out to eat. If everyone has had lunch or it is a really hot day, ice cream will win out almost every time. But if you have not had dinner, a steak is a wonderful choice. And, if you play the dinner “date” right, you can have both steak and ice cream.

In some shops, you need the discipline of waterfall to get things done. This is especially true when an outside “agency” is doing work and it must fall within certain constraints (generally budgetary). I am not stating Agile does not work here, but keep going until we run out of money and we will pray it works as a project is a fear with Agile when this type of situation is encountered.

What I personally find is most effective is a mixture of the two. You need a certain amount of discipline and sign off to have a successful project, so pulling the gates from waterfall makes sense. During development, you need the flexibility to change, however, so running iterative cycles is a great option. You need to plan before developing, so forcing some type of up front documentation (ala waterfall) is a good thing (At minimum, you need a good definition of the use case with criteria of what acceptable means for the feature). But you also need representatives from business, development and test in the same team so progress is not impeded (ala Agile).

TDD Is Agile?

This is another misnomer I often hear. While TDD got it start in Agile shops, I have seen it effectively used in a variety of environments, including some that are extremely waterfall in nature. The same is true of many other Agile techniques, like pair programming. When we start mixing the techniques and the methodology, it becomes much easier to claim one methodology is superior, especially if we ignore techniques that are more likely employed by the opposing methodology.

The book often mixes the Agile technology of Test Driven Development (TDD) with the methodology, which helps build the straw man argument argument against waterfall. Unless we assume it is impossible to unit test in an upfront manner with waterfall, we cannot use TDD against the waterfall methodology.

Summary

Neither Agile or waterfall is a superior methodology in all cases. When done well, with the right business culture, either can be extremely effective. Done badly, both can be detrimental. Bad waterfall generally gets bogged down in process, delaying work that needs to be done. Bad Agile leads to unplanned and undocumented work, which requires tons of rework to get to a stable release.

In my experience, I find Agile done bad to be more dangerous, as overly rigid process generally has less impact on quality and maintainability. But I am still more inclined to push Agile as the primary methodology, as I find good Agile much more likely to produce good results.

(Not quite true, as I find using the gates after you pull the trigger to release, adds control to the chaos that might otherwise ensue).

Peace and Grace,
Greg

Twitter: @gbworld

SOA Lessons: Insulate Your Client

In my last post, I lamented on the idea of creating an external layer where all of the services sit in a single project. In this post, I would like to talk about the idea of passing data directly from internal services through an External API without mapping the data. This topic was covered a bit differently in a previous post if you would like to look at the issue in greater detail.

As a disclaimer, this post focuses on a particular set of problems I have seen with immature External APIs that may not manifest themselves in more mature SOAs.

External API consumers are valuable to business. If they aren’t, there is no reason to have an External API. Initially, the external clients may not serve much value to your business, but overtime they do. This is especially true in an ECommerce situation, where you clients are using your APIs to help you sell. But this “truism” applies to all sorts of businesses.

From the standpoint of the development team, the external consumer is often “out of site out of mind”. Unless you are attempting a coordinated effort (a topic for another blog post?), your support and infrastructure teams will often have more of an idea of what your clients are doing than the development team.

The primary solution would seem to be “make the external client a first class citizen” and this is a dynamite idea. The problem is external clients are often not easily monetized, making it hard to place a priority on them.

Standard SOA

The title of this section is a bit misleading, as it suggests I am going to guide you through the creation of a “standard” SOA. Instead, I am going to cover a generic SOA setup I see in many organizations.

At the bottom layer of the SOA, services are created to expose persisted state (data). The services at this level may present objects that represent rows in database tables, especially in less mature systems, but more often tryt o distill the data a bit to serve up objects needed by various business applications.

On top of this layer, you find services that aggregate multiple services. This layer or layers of the SOA, models are being created that can be consumed by user interfaces. And it is at this layer many SOAs create the objects consumed by both internal and external clients.

The topmost layer comes in two flavors. The first is what my current client calls a “domain services layer”, which serves to map the aggregate service model to a domain model for the external world to consume. The other is a pass through layer in which the objects of the aggregate layer pass through the external service, which is not much more than an endpoint on an external service.

Insulating the Client Through Process

When the external layer is a pass though layer, breaking changes to objects on the aggregate layer will not always break the pass through. In cases where there are no changes to the external layer, service references are updated and the service is deployed. But the client can’t consume them.

To insulate the client from these changes requires process. A proper versioning strategy must be put in place and older versions of the internal services must be kept up until all clients have moved to the latest version. This also means external clients must be included in the testing process, even if their inclusion is only during the User Acceptance cycle.

In general, this works best if the External API team has some measure of governance over the internal services it consumes. At minimum, the external team needs the ability to issue a go – no go order when breaking changes occur in the pass through models or force the internal service to leave an older version alive while clients migrate to the new version.

If process and a versioning strategy are not in place, it is dangerous to maintain your external API as a pass through layer.

Insulation through Domain Models

Another means of insulation is to set up a Domain Model for the external API and “mapping” the returns from the internal service(s) to the External Domain Model. The main negatives to this approach are a bit of overhead (performance) and a maintenance requirement, especially when the maps are hand coded.

The benefit is breaking changes are instantly seen when the service reference is updated, as the changes now break the mapping. This insulates the client from change, as this breaking change has to be fixed. As the exception can often be fixed through mapping changes alone, the external client need not know the software was even changed, so the external API service can undergo a minor, rather than a major, revision.

Process or Domain Modeling?

The question comes to which should you use … process? domain modeling? both?

In my experience, attempting to solve a technological problem with process alone (or, expecting people to follow standards and rules) only works in an organization where software is reviewed completely prior to deployment. I have certainly worked in organizations with this commitment, but for every company I have consulted that had governance over process, there are 10 that do not.

This leads me to the domain modeling approach and insulation through adherence to contract. The entire underlying system may introduce breaking changes, but as long as the changes can be mapped to a consistent model, the outside world has no clue these breaking changes occurred.

The Cost of Change

As a kind of summary, I want to talk about how much change costs, or more specifically, how breaking changes to external APIs can be very costly.

Initially, an External API is a cost center. Until there is adoption, there is no financial benefit to having clients consume your data. But, even at this stage, failures in the API cause clients to shy away from using them. Enough issues and the stability of your API becomes public and most sensible people avoid it. This ensures the API will never be anything other than a cost center. Worse, it can be the proverbial albatross around your neck.

Over time, the stability of the API and its contracts, becomes more critical, as more and more clients begin to use the service. At this point, a breaking change is generally caught sooner, but rollbacks become extremely expensive.

While setting up mapping to an external domain model is not a cure all, it certainly adds a measure of safety for your clients to use the service.

The Point

The point here is changes that break software internally may be annoying, but they can most often be fixed without the outside world having any clue there is turmoil. Changes that break external software are more dangerous, as they cannot be hidden from view. By enforcing proper versioning strategies and treating the external API as a first class citizen, you can protect yourself from these public breakages. In cases where these processes cannot be put into place, breaking changes can be hidden from the outside world by insulating the clients by mapping to an external model.

From my experience, adding the small bit of overhead to protect the client from internal changes is the safest path, especially when you are in the early stages of creating processes to properly version change. If your organization is mature enough to have proper governance on releases and properly tests both internal AND external responses, a process driven approach is an option. And, if true performance is a showstopper, it may be your better option. Otherwise, adding a bit of insulation for clients is a very wise idea.

Peace and Grace,
Greg

Twitter: @gbworld

Domain Objects: The Importance of State

When I stoked up Windows Live Writer, my intent was to write an entry about testing. Specifically, I was going to aim at testing the domain. Then I realized I had never written an entry on domain objects and thought it was a necessary place to start.

As a disclaimer, this article is not the be all, end all of explanations of domain modeling. If you want a full treatise, you would be best reading Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. If you want to stick in the .NET world, Applying Domain Driven Design and Patterns by Jimmy Nilsson is also a good read.

What is a Domain?

Now this is the thousand dollar question. What is a domain? Rather than answer the question straight out, let’s look at a scenario. Picture a company that takes orders via phone (or Internet, if phone orders seem antiquated). There is an application to take an order, another to box the items in the warehouse and a third to ship the items to the customer.

If we look at this scenario from the database, we might see a schema much like the one below.

|
Above taken from Adventure Works, SQL Server 2008 R2

Now, if we take the schema above, we can build each of the applications by mirroring the schema as objects in the applications. This is acceptable, but not optimal. In addition, we are potentially exposing sensitive customer data, like payment information, to employees who have no need to see the information.

Let’s talk about a customer for a second. In the ordering application, all of the customer information is important. We need to know the customer’s name, address or addresses (if there are different home, credit card and shipping addresses, for example), at least one telephone, and at least one form of payment information. This application may be served well by simply mirroring the database schema. In other words, in the order “domain”, we need all types of information about a customer.

When we move to the shipping domain, however, we only need a name, phone number and shipping address. The customer object may be better set up like the following C# code:

public class Customer
{
    public string Name { get; set; }
    public string AddressLine1 { get; set; }
    public string AddressLine2 { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string PostalCode { get; set; }
    public string Country { get; set; }
    public string PhoneNumber { get; set; }
}

In the warehouse domain, we don’t really need to have a customer object at all, as we simply need to pick some items and put them in a box. To aid the application in the shipping domain, we can print out a order label that can be scanned.

In the above example, there is one application per domain, but we can have multiple applications in a single domain. We can, theoretically, have applications that cross multiple domains, but that is a concept beyond this post.

Now we can return to the question: What is a Domain? A domain is a specific area of influence for an application. In my examples, I use the idea of an order domain, a warehouse domain and a shipping domain. Perhaps a weak example, but it shows that an object can radically change from the expected object in a relational database. And that is worth the price of admission (currently free).

Creating Domain Objects

In general, a domain object is an object that holds state. While there are patterns, like Active Record, that have “smart” objects that contain behavior, the norm for the domain are containers that hold current information about an object, or its current state. The repository pattern, which separates behavior and state, is much more common today.

To put it in a way that jogs memory, just think of BS. Domain objects deal with the S (state) in BS (behavior and state) and not about the B (behavior).

Since we are only dealing with state, it is extremely easy to make our domain objects, as we can use the simple property format:

public class ObjectType
{
    public Type PropertyName { get; set; }
}

When I start a new project, the first folder I create is the domain folder. I then set up two projects, one for domain objects and another for domain specific exceptions. I will then determine whether or not to test the domain objects, which is the subject of the next post. The Visual Studio project will look something like this:

I will cover more of the project setup I use in future posts.

Important Points

1. A domain is an area of influence. When we develop an application, we need to find the Subject Matter Expert (SME) in that domain and have them help us determine the domain objects.
2. Domain objects handle state and do not deal with behavior.
3. Domain objects should be a primary or “first” concern when developing an application.

See you at the next post, which covers the question “should I set up tests on domain objects?”

Peace and Grace,
Greg

Twitter: @gbworld

ASP.NET MVC 3 Beta Announcement

Scott Guthrie got up early today and announced the ASP.NET MVC 3 beta, as well as NuPack (open source manager for .NET) and a Web Matrix 2 beta. You can read about it here.

Downloads

• ASP.NET MVC 3 beta
• NuPack
• Web Matrix 2 beta

Have fun!

Peace and Grace,
Greg

Twitter: @gbworld

Ellie Potvin – Rest High on that Mountain

Having a child that fought cancer and walked very close to the edge of the cliff changed our family forever. Fortunately, our dear Miranda walked through the fire and made it out of the other side of the valley. Below are two pictures. The first is from the first month of her treatment and the second from last Christmas:

In the United States, 80% of childhood cancer patients survive. Through our journey, however, we have met more of those who did not. At first, I was really surprised by this, as the numbers did not work out. Then I found that the majority of the survivors are leukemia patients (primarily Acute Lymphoblastic Leukemia or ALL) and spend most of their time after the initial visit at home, only visiting the hospital when they get really sick with their counts bottomed out. The hospital is for the patients with really bad cancer (as if you can ever call it good).

Tiffany has decided to get together a group of 46 women to shave their heads for childhood cancer this September. The idea being that raising awareness also raises funding for a cure (less than 1% off the American Cancer Society budget currently goes to childhood cancer). I have reached out to families trying to give them hope and possibly lead them to complementary treatments to help their children get through the cancer treatment.

Today, one of the children we have followed for years earned her wings (a childhood cancer euphemism for passing away). We have watched the Potvins go through the throws of completing treatment, finding their dear Ellie had relapsed, go through even stronger treatments, and ultimately reach out for other options when the doctors said there was nothing more they could do.

That is the clinical side, but Ellie was not a patient, she was a lovely little girl. Below is a picture of Ellie, vibrant and full of life.

A pictures paints a thousand words and the next picture had my heart yesterday:

The black on the scan is the part of her lungs not overcome by Rhabdomyosarcoma tumors. When I saw this, I knew that only God’s intervention would stop me from reading the following words soon.

Wednesday, June 23, 2010 11:42 AM, EDT
Ellie gained her angel wings at 11:35am and rest in my arms.

You can read her Caring Bridge journal at http://www.caringbridge.org/visit/elliepotvin/journal. This is a sad day for those of us who have followed Ellie’s battle. I find myself driven to tears, even knowing I would likely read this news soon.

I would like to say rest in peace, but in the words of Mimi Avery on Facebook (mother to Julian Avery, aka King Juju, who earned his wings in January 2008):

"Rest in Peace " is for old people, children should NOT be resting , they should be healthy, running ,jumping , swinging, climbing, skipping, winning and losing games of soccer, football or hockey, painting, kissing us every single day. RIP is not for kids… Just saying…

I dream of a day when kids no longer have cancer. I pray it is not just a dream.

Peace and Grace,
Greg

Twitter: @gbworld

46 Mommas Shave for the Brave – Updated Map

Tiffany sent me a list yesterday and stated the 46 mommas wanted an updated map. Okay, so here it is.

Legend

Momma

Volunteer

Barber

Here are the stats on mommas (shavees), volunteers and barbers:

• Arizona – 1 momma
• California – 4 mommas
• Delaware – 1 Volunteer
• Illinois – 3 mommas & 1 barber
• Kansas – 2 mommas
• Kentucky – 2 mommas
• Louisiana – 5 mommas
• Michigan – 1 momma
• Missouri – 1 momma
• New Hampshire – 1 momma
• New Jersey – 3 mommas
• New York – 1 momma
• North Carolina – 2 mommas
• Ohio – 5 mommas
• Oklahoma – 1 momma
• Pennsylvania – 5 mommas & 1 volunteer
• Rhode Island – 2 mommas
• Tennessee – 2 mommas
• Texas – 2 mommas
• Virginia – 3 mommas
• Washington – 2 mommas

NOTE: There are alternates amongst the mommas, so the total ends up at 49 (if you are counting).

Here is a list of the participants (first name, last initial, state and type of participant) – click on links for donation page, where applicable:

Amy P ( AZ) Shavee
Chrystine A. ( CA) Shavee
Shannon B. ( CA) Shavee
Karen H. ( CA) Shavee
Perla S. ( CA) Shavee
Catherine K. ( DE) Volunteer
Annmarie C. ( IL) Shavee
Helen F. ( IL) Barber
Jaclyn H. ( IL) Shavee
Leanne L. ( IL) Shavee
Lisa G. ( KS) Shavee
Karla K. ( KS) Shavee
Renee C. ( KY) Shavee
Mandy Cherry L. ( KY) Shavee
Jaime B. ( LA) Shavee
Melanie B. ( LA) Shavee
AnnMarie I. ( LA) Shavee
Stacie R. ( LA) Shavee
Paula S. ( LA) Shavee
Ellen R. ( MI) Shavee
Jill B. ( MO) Shavee
Danielle C. ( NC) Shavee
Lorrie M. ( NC) Shavee
Jennifer R. ( NH) Shavee
Stephanie H. ( NJ) Shavee
Dena S. ( NJ) Shavee
Norma Z. ( NJ) Shavee
Carol B. ( OH) Shavee
Christine B. ( OH) Shavee
Darlene H. ( OH) Shavee
Laurie H. ( OH) Shavee
Jennifer Jenni P. ( OH) Shavee
Angela W. ( OK) Shavee
Helen A. ( PA) Shavee
Amy B. ( PA) Shavee
Amanda D. ( PA) Shavee
Monique G. ( PA) Shavee
Michelle K. ( PA) Shavee
Diane S. ( PA) Volunteer
Rebekah H. ( RI) Shavee
Dawn P. ( RI) Shavee
Melissa H. ( SC) Shavee
Tiffany B. ( TN) Shavee, Team Captain
Rebecca "Becky" E. ( TN) Shavee
Myriam "Mimi" A. ( TX) Shavee’
Lisa S. ( TX) Shavee
Melina B. ( VA) Shavee
Heide R. ( VA) Shavee
Brittany S. ( VA) Shavee
Amy W. ( VA) Shavee
Kelly F. ( WA) Shavee
Carla H. ( WA) Shavee

Peace and Grace,
Greg

Twitter: @gbworld

Expression 4 released

With the launch this morning at 11 AM, Microsoft has released Expression 4 to MSDN. You can now download from the MSDN subscription site. If you don’t have an MSDN subscription, you can download a trial here.

Peace and Grace,
Greg

Twitter: @gbworld

IT perspectives: Strong indications you are NOT getting it (Agile)

I have had some time lately to think about the state of development in many companies today and decided it would be a time to start talking about some of the clues I see in organization after organization that they are not quite getting it. When I say getting it, I mean they have adopted the correct path, but don’t quite understand the paradigm.

Paradigm shifts are natural parts of innovation. When someone truly looks at anything from an innovative perspective, it almost always requires throwing away old thought patterns and shifting to a new way of looking at the world. In Microsoft development, the shift from COM >> .NET (and especially ASP >> ASP.NET) required a huge paradigm shift in thinking. Unfortunately, it was still possible to hang around your old “loser friends” and not make the shift. And, it has served me nicely, as I have cleaned up a great many ASP.NET apps that were actually ASP written using ASP.NET tools.

In this post, I would like to focus on some key clues that you are not “getting it” in Agile development.

Agile Development

Agile is the buzzword everyone wants to hang their hat on. You see job description after job description touting Agile. But when you get engaged with a company, you find many of them are not really doing Agile, and most are not doing Agile well. They are still working a waterfall methodology with a bit of time boxing, some stand up meetings, and other artifacts of one of the Agile methodologies. When you examine closely, you find very little that is Agile about their implementation of the methodology.

As an example, let’s look at the average corporate entity that adopts Scrum. They will generally bring in some consulting firm to teach them the artifacts of scrum, adopt a scrum template in Team System (assuming Team Foundation Server is their source repository), and start having sprint kickoff meetings, stand up meetings and burn down meetings. They will start talking about chickens and pigs and adopt the nomenclature of Scrum. But, they most often don’t really “get scrum”. Here are a few common clues that they don’t get it.

Developer Interruptions During the Sprint

The idea of time boxing an iteration (sprint) is to keep developers active and on task. The limited time for a sprint (2-3 weeks in most companies) means you can adjust priorities rather quickly, but adjusting in the middle of an iteration is wrong. In the waterfall methodology, it was often necessary to stop a developer or a team and move them to another task in midstream. This was due to the all or nothing nature of the waterfall methodology. As business changed, you often needed to change priorities and since everyone was in a long term stream, you had to dam up the river and get people going down side routes.

With Agile, you are, at most, a few weeks out of changing developer priorities. The only reason you should have to stop an iteration is you find you are building the wrong software. And, if that happens, you failed to plan, which means you planned to fail. It is expensive to interrupt a developer on task.

Once you adopt an Agile methodology, the PM part of the team should not only be managing the plan (through standup meetings), but also keeping ahead of what is going on in the next iteration. This leads us to the next clue an organization is not “getting it” when it comes to Agile.

Meetings that Take Too Long

The goal of a standup meeting is to get a status update and determine future flow. The format is:

1. What did you get done since the last meeting?
2. What are you going to do before the next meeting?
3. Do you have any impediments?

So one developer’s contribution might go like this:

Developer: Yesterday, I got the menu roughed in, but I still have a bit more work to get it done. I am having a strange problem getting the site map to work and some nodes are not showing up.

Scrummaster: John has experience with the site map and some of the problems associated with it. I am going to have him pair with you for a couple of hours this morning and get through that roadblock.

At this rate, you can burn through the entire team in a matter of 5 to 10 minutes on most mornings, with a few extra minutes if you have to figure out who can help on a particular task. You will note that I have taken the assumption the shop does not pair program 100% of the time. I have done this, as I find few shops that have completely bought into the idea of pair programming.

By the same token, the sprint kickoff meetings should not be all day affairs. If your PM guys are one iteration ahead, then the kickoff meetings should be more focused on doling out the tasks than determining what tasks need to be done in an iteration. Certainly some new tasks may have popped up, but if the meeting is an all day affair, you have failed to plan again.

Throwing Code Over the Wall

In many traditional shops, it is quite common to see developers as people who develop … ONLY … and the QA team as the testers. The problem with this approach is you often see code with very bad flaws that should have been caught by dev pitched back over the wall by QA. You end up with this ongoing volleyball match where the code is the ball and the developers and QA people are the players. It is completely non-productive.

From the development side, you should be able to determine that your software is really working before sending to QA. This is done through unit testing and ensuring proper code coverage. With .NET 4.0 and Visual Studio 2010, there is a new tool called Pex (and Moles) that can be used to fill out code coverage with fringe conditions, so we have less and less excuses to not code tests. Add tools like Code contracts, and you not only end up covered, but you run the gamut when it comes to expressing intent of the code. It is fine if you do not practice TDD (some purists may cringe at that statement), but it is not fine to leave all of the testing to QA. Their job is quality, which means catching the conditions a developer might not think of, not testing to see if you actually did your job.

You have to decide whether you want to be a computer artist or a computer scientist. Anyone who codes blind, without proper tests, is practicing a form of computer art. One might even say voodoo art. In order for coding to be science, you have to have proof the code works as expected. Let’s delve into this with something personal for me.

In 2007, my youngest daughter was diagnosed with cancer. At 3 years old, with non-metastatic Ewing’s Sarcoma of the soft tissue, she was in a group where 100% of the participants who had her treatment protocol lived. The problem with taking that as a scientific fact, is the group had only 4 members, which makes it, statistically, insignificant. The larger group, which was statistically significant, had about a 70% survival rate if it was non-metastatic down to < 20% if it had metastasized to the lungs.

If we take this back to software, creating a small app to run the methods, or even adding a single test to significant methods, is better than nothing, but it is statistically insignificant as a measure of code quality. To have a proper method, you need high code coverage, at minimum, and preferably tests that hit fringe conditions. Without these tests, you are blindly asserting code quality … and most likely wasting both your time and that of QA.

Final Words

I would like to say the above points represent the exception rather than the rule, but that is not my experience. More often than not, people DO NOT get it, especially when there is a rather large paradigm shift in thinking (waterfall to Agile, for example). Some may argue that not “getting it” is less damaging than not “moving to it”, but I am not convinced that is always true. Sometimes bad Agile practices (waterfall mentality with an Agile methodology) are far more damaging than sticking to a waterfall methodology.

This is a good start on some of the practices that show an organization is not “getting it”. Other topics we will explore are not getting the paradigm shift from ASP to ASP.NET (or COM to .NET), not getting applications, and the like. I had envisioned getting into one post, but I need to keep this to few enough words that people will actually read it.

Peace and Grace,
Greg

Twitter: @gbworld

When does Visual Studio 2010 RTM?

This has been an interesting year. I currently have a nice VHD with Windows Server 2008 R2 installed that I dual boot with in Windows 7 (honestly one of the best features in Windows 7 for a betaware guy like me).

In previous release timeframes, we have downloaded the RTM bits long before the public could buy a shrink wrap copy. In fact, the general has been launch in Spring (around March) with a MSDN download in November. This time it could not happen due to performance issue, which forced additional builds prior to RTM. I have been anxiously awaiting the bits.

I wish I could tell you “go to MSDN and download”, but I can’t or that you can get involved in some Microsoft program and download, but I can’t. I wonder if the TAP folks are doing better. I would assume so, but I just don’t know, as I don’t currently have access to customer facing programs.

If you have been in a cave, VS 2010 is set to launch next week at DevConnections. Perhaps this is the reason the release has been held so close to the vest. I imagine there is some deal in place to ensure the bits do not leak prior to the launch so Microsoft can proudly hand out the bits to those who paid for the conference.

The good news is the launch is only a few days away and it is highly likely we can download from MSDN about that time. Until then, I am playing with my beta.

I felt like stating they were already released, but I think most of you know it is April Fool’s Day.

Peace and Grace,
Greg

Twitter: @gbworld

Adventures in ASP.NET MVC 2: Project initiation

I had a bit of downtime with my new position and figured I could focus on getting the 46mommas.com site up and running. As i am Microsoft oriented, it only made sense to use ASP.NET MVC 2. As I am a bleeding edge type of guy, I figured I would use parts of Enterprise Library 5 in the solution. I am mostly interested in seeing what has been done in Unity 2.0.

Initial Steps

First I had some software to download.

• ASP.NET MVC 2.0
• Enterprise Library 5.0 (could have opted for Unity 2.0 only, but if I am playing, I might as well play ;->)
  NOTE: If you want Unity for Silverlight, there is a download on the Unity download site for you
• Possibly some other software, including:
• Spring.NET – Although there are overlaps with Unity, so not sure on this one
• jQuery – This is a given with ASP.NET MVC
• Other?

Fortunately, the install process is fairly fast, so I am done in just a few minutes.

The Project

In September of 2010, my wife and 45 other women are going to shave their heads for childhood cancer awareness. The venue is not yet figured out, but theey are aiming for national television. This gives me some thought on features needed and desired.

• Project information page
• Information pages for each participant (who they are, why they are involved)
• Ability to have media (movies, etc)
• Some form of login for participants to add content
• Press are for press releases, etc
• Ability to see participants on a map (Google maps?)

I also wanted to create a short URL feature that jets a person to a page, so this is going to be my first experiment with ASP.NET MVC routes. So, routes is the next article in this series.

Other Notes

That pretty much does it for this particular post. I am already rolling on the project, so I will update with more articles over the next few days as I finish the original implementation.

Peace and Grace,
Greg