A Technical Debtor

Let me preface this by saying that I couldn’t keep up with Dave, and he has much more to say than I could capture here. He’s quite willing to discuss this more. Feel free to contact me for his contact info

Problem statement: architecture is challenged by a perception that design and development standards are too abstract or irrelevant. This is exacerbated by the misperception that agile processes eliminate the need for good design and architecture practices. So, how do we build enterprise-class solutions and assure the adoption and use by software and EDW/BI teams?

Gartner gives good guidance for CIOs in creating an EA plan. However, the framework itself is an implementation choice, be it TOGAF or Zachman (ZIFA).

“Nothing is particularly hard if you divide it into small jobs.” Henry Ford

There’s lots of reasons that we have problems with this:

• we get less time than we need
• our business world and rules are complex
• stuff happens
• we have lots of processes and standards… but they don’t tell us how to ensure value
• general mandate to create business value

Concentrate on reducing friction and improving speed. All the pieces must work efficiently together… or value is lost.

How do we get there? Some lean concepts:

1. simplify your business model
2. modularize the blocks
3. standardize the interfaces
4. look at the points of rapid change
5. know the overall economics and throughput
6. focus on the constraints on value throughput
7. manage to the vital signs (3-5 KPIs)

What do we need to know? Strategic goals, operational goals and operational capabilities. Our intuition is valid – there is a complex neurological engine that solves complex problems. However, we need to formalize this intuition; otherwise, we end up with assumptions that cause problems.

How do we get there? Business capabilities, technical capabilities, organizational capabilities, integration capabilities.

Steps

1. define dimensions and service level expectations
2. use top-down thinking in combination with bottoms-up
3. adapt use case outline to manage user story inventories
   • connect User Stories together in context with the business value
   • carve up the problem into bite-sized pieces
4. map business architecture to solution design architecture components

What are the dimensions of alignment?

• Business processes
• Domains
• Environments

Managing User Story Inventories for Completeness

• helps ensure that we cover the basic requirements (precedence, end states, exceptions, business rules, UI specifications, domain, environment)  for each user story
• spreadsheet-style tools, like Rally, can help

The structure of an organization is slower-moving than the requirements or the capabilities. The architecture shouldn’t need to change unless the company change what they’re doing (or unless a technology shift occurs).

Michael Porter (“Competitive Advantage,” 1985) suggested that there are 5 primary activities we do as a business (inbound logistics, operations, outbound logistics, market/sell, service) to create value. Secondary activities (procurement, HR, technological development, infrastructure) support the creation of value. Projects that don’t clearly affect the value chain are questionable.

Remember: Strategic Goal => Operational Goals => Operational Capabilities

Once we know what we need to do, we can design the business architecture and the technical architecture. The business architecture should be a logical arrangement of tasks or capabilities, but does not dictate organizational structure or roles. Note that it is the business processes, not the tasks, that provide business value.

For those of you who have been around since the VB6 days, you surely remember the interesting rounding behavior of CInt(x). Specifically, it rounded a number ending in .5 to the nearest even number. That is, CInt(2.5) rounded to 2 and CInt(3.5) rounded to 4.

This behavior still exists in VB.NET. No real surprise there. And, to be honest, I don’t mind it that much. When I see “CInt,” I really don’t have any preconceived, intuitive understanding of what it does.

Math.Round(x) is another question entirely. I expect it to… well, round. The way I expect. The way were all taught in second grade. Point-five and bigger rounds up; smaller than point-five rounds down. Every time. Not rounding up sometimes, rounding down other times.

But, after that rant, you’re not going to be surprised when I tell you that Math.Round behaves just like CInt by default.

Want proof? Just see what this code outputs:

Console.WriteLine(Math.Round(1.5))
Console.WriteLine(Math.Round(2.5))
Console.WriteLine(Math.Round(3.5))
Console.WriteLine(Math.Round(4.5))

There is an easy way to make this code work more intuitively. This code yields the results you’d expect:

Console.WriteLine(Math.Round(1.5, MidpointRounding.AwayFromZero))
Console.WriteLine(Math.Round(2.5, MidpointRounding.AwayFromZero))
Console.WriteLine(Math.Round(3.5, MidpointRounding.AwayFromZero))
Console.WriteLine(Math.Round(4.5, MidpointRounding.AwayFromZero))

The insidious thing about this problem is that you often have to create very specific test cases to uncover this issue. It’s particularly nasty, since the actual behavior differs very slightly from the intuitive behavior.

You’ve been warned.

Just got the e-mail from Microsoft, so it’s official. I’ve been renewed as a Microsoft MVP for another year!

And, no.. this isn’t an April Fools’ Day joke. I’m an April 1 MVP.

Congrats to all those renewed, and especially to those who were awarded for the first time.

One of the places lacking good VB support was the Microsoft Patterns & Practices’ Composite Application Guidance for WPF and Silverlight (formerly code-named "Prism"). The P&P team is now releasing VB versions of the QuickStarts, Hands-On Labs, and How-to Topics!

Get all the good stuff here

This download is provided to help Visual Basic .NET developers use the Composite Application Library. While Prism is not yet 100% VB, this is a big step in the right direction. The VB code was reviewed by VB Language PM Jonathan Aneja as well as VB Doc Writer Doug Rothaus, so you can be sure this won't be the usual "C# run through a code converter" translation.

Great work by the team!

My past experience with WCF services has followed a slightly unusual path. For a variety of reasons, most of the services I've written have consisted of an interface and an implementation. Pretty straight-forward thus far. However, where it gets a little unusual is in the hosting mechanism. We're using Windows services to host of WCF services. This works out well for us, since these services live on intranets, and aren't publicly exposed.

When looking at Azure, services are a little different. It's probably more akin to creating IIS-hosted WCF services. When you right-click on the web role and add a WCF service, it adds this wacky .svc file -- something I've never run into using Windows service hosting.

As if that weren't enough of a change to wrap my addled brain around, there's a pretty big issue around adding a service reference. Specifically, Azure doesn't expose wsdl very well. Sure, you can hit http://myapp.cloudapp.net/myservice.svc and it will give you the standard web page that lets you know it's listening. But... what's wrong with this picture?

That's right... the Azure service tells you to get the WSDL to build your proxies from a URL that is somewhat "non-standard." In other words, you can't get to it.

Simple workaround: add a service reference against a local copy and change the URL to point to the cloud. Since Azure services can only listen on port 80 (for http) or port 443 (for https), there's no need to specify the port number.

I've had a number of conversations lately where I argued that software development is much more akin to craftsmanship than to engineering. This usually leads to a lively discussion, especially in an informal context.

Seems I'm not the only one thinking this way. Uncle Bob (Robert C Martin) posted a link to the Manifesto for Software Craftsmanship.

It'll be interesting to see what degree of impact this has on the development community.

I'll be presenting on Azure here in Fort Collins tonight, and again in Boulder on March 24th.

The talks will focus on providing an introduction to Azure, including working through some of the common pain points (such as debugging). I will, of course, be posting tips and tricks here as I get them in a coherent format.

What techniques can you use to get agile practices into a waterfall project/legacy code base?

Approaches

Small greenfield project

1. smaller, greenfield project
2. started with source control (moved from Source Safe to Subversion)
3. once SVN was in place, other tools were able to be used
4. starting to do CI (TeamCity is free for small teams; can target multiple build mechanisms)
5. then the door for NANT (or other unit testing) is open; not only does the code compile, but nothing is broken
6. integration tests can also be automated (different build cycle)
7. important to pick the right battles

Larger legacy system

1. subverted a larger system
2. able to show improved testing, better design, code coverage
3. bad (badly designed) code suggests bad tests (likely written by the same people)
4. first step was source control
5. second step CI build
6. third step was to move to DI in order to decouple code

Breaking sproc dependencies

1. use of WCF services is a great way to put a facade around sprocs
2. the requirement for WCF services to implement contracts allow testability

A different approach is to decompose large specs into smaller features so that developers can work in smaller iteration.

At least three vectors for change: developers, business people, technical. There are different techniques with these. It's important to prove the value of the techniques. The names we use aren't really important.

Keys to success

Using the term "lean" development is more politically acceptable than "agile." Manufacturing is moving to lean processes, and it appears to have some government buy-in. This leads to easier PM buy-in.

We need to focus on the fact that "agile" is really about minimizing risk, and increasing productivity.

The definition of "done" is key -- including communicating that definition to management.

Success really depends on having the right people in the driver seat; it's hard to convince decision makers to take a risk on large, flagship products.

Customers must be the ones dictating priorities. However, as developers, we need to be setting realistic goals and expectations. This may require going back to the business people to negotiate.

Communication is key. The solution is not to block discussions, but instead to increase the level of education and communication.

Establish your technical credibility. Once you do this, you'll have support. Sometimes, you'll need to sell management on the benefits. Couch this discussion as a value proposition for the manager to make them look good.

Patience, young grasshopper.

Resources

• Agile Product Design blog
• David Anderson's "Agile 08" speech
• The Toyota Product Development System

I have to admit that when I heard there was a keynote this morning, I was somewhat taken about. The very notion seems to be antithetical to the notion of Open Spaces. On the other hand, getting the chance to hear Ward Cunningham speak was well worth the "architectural purity" of the organizational principles.

Intro (Alan Stevens) referred to Channel 9 video with Ward Cunningham being interviewed by Scoble

WC: "the only thing I'm sure of is that [the future] will involve cloud computing"

AboutUs.org == "self-organizing" wiki based on the notion of "list keepers"; has an "about page" for each domain on the internet

The swim system for use case visualization

• used by Eclipse Foundation to manage contributions to Eclipse
• basically organizes use cases into "swim lanes" (analogous to life span of UML sequence diagram objects)
• built a test runner based on a DSL to translate swim lane items into tests
• since a DSL backs a visual system, business people can understand it, and have relevant discussions about the business
• test results also include an index back into the source code
• application uses test outputs as end user documentation; "explorer" allows the user to see all use cases related to a particular action (e.g. button click)
• swim lane diagram allows you to run the automated testing to a particular step in the code then "go live" for detailed stepthroughs

In lieu of a Q&A session, a fishbowl to design "nSwim" or "Visual Swim" (ended up being a Q&A session anyhow)

• since the sequence is time-sensitive, all time requests go through a stored procedure that was capable of "advancing" the database clock by modifying the returned time
• no concurrency testing
• how is this different than FIT?
• very similar but instead of parsing HTML to determine the system stimulus, it gets put into a text file
• with FIT, there isn't a good system to make HTML painless
• proposed modules: parser, test executer, rendering engine
• current implementation uses php eval command; some security concerns there
• ironic revelation: no unit testing on swim lane testing framework
• consider using dynamic languages (like IronRuby) as a DSL

Came across this great quote last week: "Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand."