Arnon's shared items in Google Reader

Singularity: Microsoft's Open Source Operating System

2008-11-18T14:49:00Z

The second release of the Singularity Research Development Kit is now available as both source code and as a bootable CD. Singularity is an operating system based almost entirely on managed code with a very high degree of isolation between processes. In an unusual move by Microsoft, Singularity is soliciting patches and offering full developer rights on CodePlex. By Jonathan Allen

IBM's alphaWorks has released HeapAnalyzer 2.9, a tool for locating possible memory leaks through "heuristic search engine and analysis of the Java heap dump in Java applications.

2008-11-21T19:49:32Z

IBM's alphaWorks has released HeapAnalyzer 2.9, a tool for locating possible memory leaks through "heuristic search engine and analysis of the Java heap dump in Java applications. Java heap areas define objects, arrays, and classes. When the Garbage Collector allocates areas of storage in the heap, an object continues to be live while a reference to it exists somewhere in the active state of the JVM; therefore the object is reachable. When an object ceases to be referenced from the active state, it becomes garbage and can be reclaimed for reuse. When this reclamation occurs, the Garbage Collector must process a possible finalizer and also ensure that any internal JVM resources that are associated with the object are returned to the pool of such resources. Java heap dumps are snap shots of Java heaps at specific times." This is a bug fix release.

Implementing Methodologies

2008-11-21T19:26:11Z

I am writing this in a bar in Malmo. Sitting with a bunch of guys and discussing software methodologies. I had an observation that I really feel that I should share.

Most software methodologies are making a lot of implicit assumptions. The most common implicit assumption is that the people working on the software are Good people. That is, people who care, know how and willing to do.

This work, quite well, in the early adopters phase, since most early adopters trend toward these set of qualities anyway. The problem is when the early adoption phase is over, and the methodologies hit the main stream. At this point, the implicit assumption about Good people no longer hold true.

Just to annoy Scott Bellware, here is a big problem that I can find with Lean just from the things that I heard about Lean from him. Toyota hires the top 2% of the engineers that they interview. A lot of the methodology assume a competent team, or at the very least, a competent chief engineer.

I don't think that I need to state that competency is not universal.

If your methodology assumes competence, and most of the methodologies that we (as in I and like minded people) would find favorable do assume competence, it is going to fail in the treches.

Cucumber: The Latest in Ruby Testing

2008-11-19T19:35:20Z

Testing is a firmly ingrained part of the Ruby culture: you probably ran across Test::Unit not long after you first started writing Ruby code (though it wouldn't be surprising if you ignored it for a while). But it hasn't been a static part of Ruby - we've seen the simple availability of tests evolve into test-driven development (TDD) that in turn gave rise to behavior-driven development (BDD). Along the way, Ruby has spawned a variety of testing tools and frameworks. The latest, Aslak Hellesoy's Cucumber, is the latest addition to the RSpec family of tools.

Cucumber is designed to allow you to execute feature documentation written in plain text (often known as "stories"). I've been experimenting with it as a replacement for integration tests in Rails. With Cucumber, you can write tests that look like this:


Scenario: See all vendors
    Given I am logged in as a user in the administrator role
    And There are 3 vendors
    When I go to the manage vendors page
    Then I should see the first 3 vendor names

With Cucumber, that it an executable specification that you can discuss with the customer and then use to verify the correct behavior of tests. Behind the scenes, you make it work by writing "steps," which are regex matchers that execute Ruby code. Here's one of the steps for that scenario:

Given /there are (\d+) vendors/i do |n|
  Vendor.transaction do
    Vendor.destroy_all
    n.to_i.times do |n|
      Factory.create(:vendor, :business_name => "Vendor #{n}")
    end
  end
end

Ideally, you'll do this all in true BDD fashion: write the Cucumber features first, watch them fail, implement code to make them pass (with lower-level tests written with RSpec or Test::Unit), and repeat.

Cucumber is under rapid development, but it's already a useful part of my testing toolbox. In addition to integrating with RSpec and Rails, it works with Merb, Sinatra, and the Webrat web-testing framework (as well as, of course, pure Ruby projects). It also has translations into 20 languages and the ability to run FIT-style tabular tests. If you're looking for a higher level of abstraction in your tests, it's definitely worth checking out.

Supported by: ActionGear is a menu-bar app for task management on your Mac. It's lightweight, quick, and helps you get stuff done. Try it out for free.

Joe Homs: A Shift In Attitude

2008-11-19T20:14:10Z

Agile is about a shift in attitude more than process. It requires a shift in focus that is easy to explain, but hard to put in practice.

A useful way to view making the change is as an investment. There are many advantages to thinking this way about how you change an organization.

Being disciplined about investing in people, testing out theory, evaluation and constant improvement go a long way.

When you look to implement this kind of change, process only takes you part of the way. The mechanics of analysis, for instance, can be taught in a few weeks, but it takes a deliberate shift in thinking as well as practice to get good.

Shifting language is a good first step to shifting attitudes. Language around collaboration rather than commitees and processes. Shifting from requirements to goals and priorities.

When you change language, you can start to change minds. It’s a long road and it helps to have experts to guide you along the way. Don’t expect a magic process and if you work with me, expect a conversation.

Does Adobe Have What It Takes To Win the RIA Race?

2008-11-18T16:56:19Z

Blogger: JP Morgenthal

I’m attending Adobe MAX this week in San Francisco (Nov 17-19, 2008). There’s been some very strong announcements by Adobe regarding the expansion of the Flash platform for enterprise and consumer markets. Through it all one craw still stick in my hat and that is does Adobe have what it takes to win in the rich internet application race?

Take a quick glance at the RIA market and you will see that Adobe has a very strong presence in everything from media to enterprise applications. With support from the likes of Salesforce.com and SAP, it would seem that they are a clear market leader. That is if you discount Ajax as a platform unto itself and the fact that Microsoft has been a keen comeback competitor. Moreover, Google is not likely to go linger about quietly in this race.

Additionally, up till now, Adobe’s success has been its ability to play nicely with other platforms. PDF readers and Flash plug-ins are available for just about all critical platforms. Will attempts by Adobe to take an ownership stake that steals thunder from these platforms affect their status? To answer this we need to look at who would be affected by this.

The most significant victim is the desktop Java Runtime Environment. The write-once, run-anywhere mantra is slowly being consumed by the Flash player and Adobe AIR. Moreover, with Sun’s inability to gain support for Java FX, their current structural instability, Adobe’s growing presence on the desktop and in the browser, and the increase in the number of Flex programmers, the Java applet should be nothing more than a memory within a couple of years.

Next in line to be impacted is Google. Google is a strong component of Ajax and invested heavily in tools and technologies that leverage Ajax for rich internet applications. Unlike Sun, which has been unable to leverage their large installed base of server-side developers, Google has enabled Web developers to deliver very usable Web applications without requiring a significant learning curve. Moreover, Google's main revenue stream is advertising and Flash-clients consuming Google services without also delivering the associated advertising has a limited life span. This will require Google to act as a competitor to Adobe in the RIA race.

Finally, and never to be discounted, is Microsoft with Silverlight. Currently a nascent player, Microsoft is bargaining for a position at the table and does not like to lose. Microsoft’s .NET platform, which is the basis for Silverlight, has some powerful application features and offers more programming languages than just ActionScript, which could be an influential factor in attracting developers to the platform. In addition, there are a number of .NET programmers now familiar with XAML and Windows Presentation Framework.

Adobe has always offered the market good adjunct capabilities, I hope with this recent attempt to gain adoption of a much larger platform, they haven’t bitten off more than they can chew.

How Toxic is Your Code?

2008-11-21T06:26:24Z

Erik Doernenburg:

Now, as a developer, how do you help managers and business people understand the internal quality of code? They generally want a bit more than “it’s horrible” before they prioritise cleaning up the code over implementing new features that directly deliver business value. Or even: how do you figure out for yourself how bad some code actually is in relation to some other code?

Nice visualization of problems in a Java codebase. Given that I'm currently involved in assessing a 15000 line Rails codebase, I wonder whether something similar exists for Ruby?

Jesse Liberty’s Silverlight tutorials in PDF format.

2008-11-19T04:17:08Z

Ever since reading Programming C# I have been a fan of Jesse Liberty’s unique way of writing learning material and so when I was looking for Silverlight content I was very pleased to find Jesse’s tutorials.

I found these tutorials useful however I am one of those people that need to print material that I use to learn from rather than flipping from window to window (or monitor to monitor). So as per my modus operandi I condensed Jesse’s tutorial’s into a single PDF and you find it here if your like me and prefer to print the whole lot out. Here are the original posts.

Stealing from your client

2008-11-21T12:24:07Z

I had a (great) talk yesterday, introducing Active Record. During this talk, I reused Jeremy's statements about data access. If you write data access code, you are stealing from your client.

Frans Bouma puts it beautifully:

No customer should accept that the team hired for writing the line-of-business application has spend time on writing a report-control or for example a grid control. So why should a customer accept to pay for time spend on other plumbing code? Just because the customer doesn't know any better? If so, isn't that erm... taking advantage of the inability of the customer to judge what the 'software guys' did was correct?

The context for Frans' post was a design decision from the Entity Framework team. I read Frans' post first, and I didn't quite know how to react to it, until I saw what the proposed design is. You can read the entire EF post here, but I'll try to summarize it so you can actually understand the point without going and reading the whole thing.

The problem is supporting change tracking in disconnected scenarios. In particular, you take an object from the database and send it to the presentation layer, some time later, you get the object from the presentation layer and persist it to the database again. There is a whole host of bad practices and really bad design decisions that are implicit in the problem statement, but we will leave that alone for now.

This is still a pretty common scenario, and it is more than reasonable that you would want your data access approach to support this.

Here is how you do this using NHibernate:

session.Merge( entityFromPresentationLayer );

Frans' LLBLGen support a very similar feature. In other words, it is the business of the data access framework to do this, none of the developer's business to do any such thing.

The current proposed EF design problem can be summarized in a single line.

context.ChangeRelationship(
customer1,
order1,
c=>c.Orders,
EntityState.Added);

This is code that you as the user of EF, is supposed to write.

If you write this type of code, you are stealing from your client.

This design violates the Infrastructure Responsibility Principle: Developers doesn't write infrastructure code for supported scenarios.

In other words, it is okay not to support a feature, but it is not okay to say that this is how you are supporting a feature.

This Is Broken, By Design

Designing Enterprise IT systems with REST

2008-11-21T16:21:05Z

My final presentation for the week is up on SlideShare.

At first I was worried this might be a bit too "out there" , but feedback has indicated the presentation was well received and provocative in the right ways, particularly in getting people working on REST to talk more about areas that have been usually punted, particularly the design of "interaction-oriented" interfaces in hypermedia, using POST.

Great seeing Jim, Steve again, and meeting Leonard and Ian for the first time. Though they left the conference before my session, I also briefly got to meet Tim, and Mark Nottingham, two leaders in this space whom I've long respected.

If the Chief-Architect doesn't decide... who does?

2008-11-21T10:04:12Z

Yesterday I read this great article about VS.NET's technical roadmap, posted by Rico Mariani. Rico is the Chief Architect of Visual Studio, and he explains what that title means as follows:

I am the Chief Architect but I'm also *only* the Chief Architect, I don't make the final decisions about what goes in the product, not even combined with the other architects. Jointly we come up with the long term technology roadmap, it indicates key problems that need to be solved for the long-term health of the product among other things, but these things cannot usually be mapped directly in to features in a particular release. So, while it's true that I have a significant effect on what we do, it is inadvisable to take any of what I write as some kind of commitment to deliver particular features; rather I talk about examples of things that we might do that are in line with the roadmap.

If Rico doesn't decide what's in the package, then... who does? And more importantly: how can a person who's not the chief architect, decide what's included in a version? Aren't decisions about what's in a version fundamentally important for the architecture of a version? I think it is, despite the fact that everything is done as modular as possible.

Of course, another question arises: why is the chief architect not given the right to decide what's in the version of VS.NET? Interesting team management, if you ask me. For example: if for feature group X, the system itself (the VS.NET framework) has to get a new subsystem, and X isn't included, the new subsystem is unnecessary. I wonder if Eclipse, with its relatively small team works the same way...

QCon San Francisco 2008 - Architects & Agilists

2008-11-21T00:38:43Z

The QCon San Francisco 2008 conference was opened with an interesting keynote by Rebecca Parsons and Martin Fowler. In their talks they addressed the often strained relationship between traditional architects and agile development and how to improve this relationship to the benefit of both the agile development team and architects. These benefits include cross-project and cross-department knowledge exchange, sharing of the architects many years of experience with the developers, and only working on the architecture that is actually needed.

The first part discussed the threat of agile development to the role of traditional architects and the distrust between developers and architects. Although many of the Ivory Tower Architect stereotypes may contain a grain of truth, the cause is often not the architects themselves. Many organizations put architects in a position that makes it hard or impossible to be successful:

Goals like achieving 30% reuse - how to measure and promote this?
Architects are not allowed to write code - so how can the architects keep up with the latest technology?
Architects are often outnumbered by developers 30 to 1 or more - this leaves no time for being involved with projects or mentoring of the developers.

Traditionally this leaves the architects with very few options, like specifying a reference architecture and requiring all projects to adhere to it, even when the architecture is not a good fit for the specific project. Not only does this clash with agile development, but agile development may even threaten this model. It is not surprising that this causes distrust between architects and agile teams.

But this adversarial relationship is not necessary. The second part of the presentation addressed how agile development allows the architects to be successful:

Visibility in progress by delivering working software every iteration, allowing the architect to be involved and react.
Up-to-date specifications of functionality through automated tests.
Extracting reusable components from working code, instead of trying to build reusable components up-front that may never be used. "After the fact" instead of "design up front" reuse.

So how can you involve the architects into the agile development process? By treating the architects as another stakeholder, just like the regular customer. The architectural requirements will need to be prioritized just like any other requirement. And requirements like "the system must be maintainable" will have to become specific and implementable, making the work of the architects more concrete and valuable.

Message Filters and Queries

2008-11-21T13:00:00Z

Since a message filter and message query share a similar heritage, let's start by looking at the conceptually simpler message filter APIs. You probably haven't seen message filters before unless you've gone out of your way to explore everything that comes with WCF. They don't appear in the ordinary use of web services.

A message filter is basically a matching delegate that works on WCF messages. There is not a lot of interesting message filter methods.

public abstract class MessageFilter
{
   protected internal virtual IMessageFilterTable<FilterData> CreateFilterTable<FilterData>();
   public abstract bool Match(Message message);
   public abstract bool Match(MessageBuffer buffer);
}

As you might have guessed, there are Match methods for both messages and message buffers. There's also this message filter table that you might not have expected. The message filter table is used to optimize execution of message filters. A message filter table contains a collection of related message filters and also has a slot for the application to store state data with each filter.

public class MessageFilterTable<TFilterData> : IMessageFilterTable<TFilterData>, IDictionary<MessageFilter, TFilterData>, ICollection<KeyValuePair<MessageFilter, TFilterData>>, IEnumerable<KeyValuePair<MessageFilter, TFilterData>>, IEnumerable
{
   public bool GetMatchingFilter(Message message, out MessageFilter filter);
   public bool GetMatchingFilter(MessageBuffer buffer, out MessageFilter filter);
   public bool GetMatchingFilters(Message message, ICollection<MessageFilter> results);
   public bool GetMatchingFilters(MessageBuffer buffer, ICollection<MessageFilter> results);
   public int GetPriority(MessageFilter filter);
}

I've picked a subset of the methods that help show how you can use the message filter table abstraction to change how the message filters execute. For example, let's say that you've got a bunch of message filters in a message filter table and two of the filters share some common work. When you execute the batch of message filters through the message filter table interface, the shared common work would ideally only get executed once. Hiding the message filters behind the message filter table abstraction allows for these types of optimizations because the black box prevents an external observer from seeing the actual computations that get done. The priority scheme is just an addon to deal with the fact that multiple message filters may match the same message.

A message query looks almost the same as a message filter except that message queries generate results instead of matches.

public abstract class MessageQuery
{
   public virtual MessageQueryCollection CreateMessageQueryCollection();
   public abstract TResult Evaluate<TResult>(Message message);
   public abstract TResult Evaluate<TResult>(MessageBuffer buffer);
}

The message query table similarly replaces results with matches. I've again picked a subset of methods that demonstrate this. You'll also notice that message queries are throughout emphasizing a multiple match mode rather than the single match mode of the message filter table. This is due to the slightly different use cases that the two were designed for.

public class MessageQueryTable<TItem> : IDictionary<MessageQuery, TItem>
{
   public IEnumerable<KeyValuePair<MessageQuery, TResult>> Evaluate<TResult>(Message message);
   public IEnumerable<KeyValuePair<MessageQuery, TResult>> Evaluate<TResult>(MessageBuffer buffer);
}

Future of Correlation Examples

2008-11-20T13:00:00Z

Last time I talked about how WCF 4.0 standardizes many different types of correlations using a query mechanism and promised to go into more detail today.

You might already be familiar with the message filter engine in WCF 3.0. If you haven't seen message filters before, then the message filter engine is just a way to check for matches in a message. For example, you might have an implementation of a message filter that uses XPath expressions and then create the filter /s:Envelope/s:Body/x:FooRequestMessage/y:OrderId to match SOAP messages with a particular structure. Instead of using an XPath to match the message content, you might instead have used an intrinsic function to match a message header or maybe even have described the filter in an entirely different language. Evaluating the message filter tells you whether the particular message satisfies the rules of the filter. The message filter engine manages a table of message filters so that the evaluation of many filters can be optimized.

For correlation, we created an equivalent to a message filter called a message query. You can think of a message query as a message filter that both checks for matches in a message as well as returns the value that was matched. For example, if you used the XPath message filter above, then it would tell you whether the message matched or not. If you used the equivalent XPath message query, then the result of the match would also give you the value of the y:OrderId node. Just like message filters, message queries are organized into tables by a message query engine to optimize the execution of many message queries at once.

You might see how to build correlations out of this query mechanism. The correlation query describes the structure or piece of information that you'll be correlating on. This information may be part of a message, a message header, or maybe even some function that gets run that doesn't depend on the message at all. Some of the queries will return matches and produce query results. These query results are then the value of the correlation that you'll be matching against. For example, your correlation query may pick out the y:OrderId node from a message if it exists. Let's say that it does and the node has the value 5. Then, the message query result is the value 5, and you can match that value against a table of previously observed values to correlate this message with some previously created state. Since you might have multiple pieces of information that are extracted, you want to have some way to hash and compare all of the matches at once. That hash is the correlation key that I talked about last time.

Next time we'll look at the APIs for message filters and message queries to see exactly how this process works.

Links for 2008-11-17 [del.icio.us]

2008-11-18T00:00:00-06:00

Alertbox: Jakob Nielsen's Newsletter on Web Usability
A set of articles on different aspects of usability

How to Control the Keyboard Using Silverlight

2008-11-18T02:45:00Z

This video shows you how to control your keyboard using Silverlight.

Meizu M8 captured on video looking smooth, doing multitouch

2008-11-20T14:58:00Z

Oh M8, you've grown up before our eyes. It seems like just yesterday we were looking at your early incarnations and their uncanny similarity to certain other devices. And how could we forget those times we spent together waiting for you at trade shows, and ~~mocking~~ checking out your early hardware? And now look at you, all grown up and caught on video doing your thing. You know what? This actually looks pretty damn nice. Sure, the obvious major iPhone influence is still there, but we have to say, Jack Wong and co. have done a pretty good job of smoothing out this UI -- and we didn't expect to see multitouch working this nicely. Of course, the clip says more than we ever could, so go and wrap yourself in your grandmother's afghan, grab a steaming cup of coffee, head out to the porch of your 19th century farmhouse, and just listen to the wind chimes and smooth sounds of this video as you take a tour of the Meizu M8... after the break.

[Via MP4 Nation Blog]

Continue reading Meizu M8 captured on video looking smooth, doing multitouch

Filed under: Cellphones

Meizu M8 captured on video looking smooth, doing multitouch originally appeared on Engadget on Thu, 20 Nov 2008 09:58:00 EST. Please see our terms for use of feeds.

Permalink | Email this | Comments

That thing about CI - Continous Integration

2008-11-20T14:47:35Z

Challenging Business requirements and the need for software development teams to remain agile and competitive while managing parallel development and releases requires a system which is adaptive to these demands. Our approach to SCM enables unlimited and adaptable process models, which are ideally suited for parallel, distributed, and agile software development. Using state of the Art technologies from various vendors to automate processes such as branching, merging, build, and release keeps you a click away from software delivery.

Comments on Communication Between Doug Purdy and Lars Corneliussen

2008-11-18T19:37:00Z

Doug has published a response to an Open Letter addressed to him from Lars Corneliussen. I think Doug did a good job in addressing Lars’ concerns, and where not, to invite discussion. I wanted to add a couple of comments of my own.

First: terminology connected with modeling, code generation and runtimes. Given my background in various modeling efforts at Microsoft over the last ten years, I know of the difficulty in seeming to redefine established terms. We faced a lot of the same concerns when, in 2004, we tried to help people understand the subtle distinctions between modeling with DSLs and using UML. As history showed, in many cases we were not very successful then, though these days (see several entries on Steve Cook’s blog especially this one and this paper from Andrew Watson, Technical Director at the OMG), most people are willing to see how both approaches may combine to bring benefits to developers across the lifecycle.

I for one have been using the term “model-driven software development” (or just “model-driven development” for short) for a number of years (actually going back to my pre-Microsoft years at Texas Instruments during the era of CASE tools). When Jack and I wrote the Software Factories book, we used the term model-driven development to encompass both “model-assisted” and “model-driven” as Doug uses those terms. We saw then, and still do today, that MDSD could involve models that transform to other models, which transform to code and which just “complete frameworks” by transforming into whatever is necessary (including no transformation) to drive a framework at runtime. For example, if I use a transform to build a logical data model, several workflows, and some service descriptions from a set of business process models, I think I’m doing more than just drawing, and I may be doing some code generation and model generation. Which of the three terms best describes this activity?

As I explained in my previous blog entry concerning the DSL Toolkit and Oslo, we are trying to help folks understand the specifics of Oslo in its first incarnation, with respect to pre-existing technologies from Visual Studio (and other parts of Microsoft). This leads us to seek terminology that helps us conduct that discussion, and in cases such as this, involves some subtle distinctions that are tough to differentiate. As Doug says: “when you a birth a new product, naming/terminology is often the most difficult aspect of the process”.

Second: Open Microsoft and Eclipse Modeling Project. I second Doug’s remarks wholeheartedly. I’d especially like to see discussion on relationships between EMF and oAW technologies.

4 Big Ideas For Management

2008-11-20T05:23:04Z

If you want to dig a little deeper into new BIG ideas surrounding "management", I'll recommend the following four (have fun, it will take some time :))

Socialutions (free ebook)

"Companies must begin to apply Socialutions to their existing and future problems before the problems become social and public relations nightmares. For this reason we have just released a free eBook titled Socialutions: New Management Methods for the Social Era. This is a short ebook has nine chapters which cover the following topics:promotes this concept and is a movement for users to organize and set the agenda for the future of the web."

Bioteaming (free manifesto)

"A Conceptual Framework For The Successful Management Of Physically Distributed Collaborative Business Networks And Highly Mobile Virtual Teams."

Tribes (free audio book by Seth Godin)

"A tribe is any group of people, large or small, who are connected to one another, a leader, and an idea. For millions of years, humans have been seeking out tribes, be they religious, ethnic, economic, political, or even musical (think of the Deadheads). It's our nature."

Peer-To-Peer

"P2P is a specific form of relational dynamic, is based on the assumed equipotency of its participants, organized through the free cooperation of equals in view of the performance of a common task, for the creation of a common good, with forms of decision-making and autonomy that are widely distributed throughout the network."

Project Animals: The Deadly Basset
I was brainstorming for some ideas to keep me busy the next few months (only got a gazillion ideas, ...
Most Important PM Task
What is the most important task of a Project Manager? (makes a great dinner discussion if you want t...
25 Sure-fire Ways To Motivate Your Team Members
Of all the resources utilized during a project, the team working on the project is the most complex ...
WTF: Project Management Theories?
It is amazing how few Project Managers that are trained in a certain method actually know the underl...
Sims Project Model: Bert's Lack Of Recognition
If we take the ideas behind The Sims to a more office like situation, consider the following s...

4 Big Ideas For Management

Peter Gillard-Moss: That's right: blame Agile

2008-11-19T19:19:00Z

Before we start a small warning. This is a rant and as such contains certain properties common to rants such as emotionally overstating unimportant points, glossing over and confusing important ones, over decorative language and taking the odd innocent as victim. Bearing this in mind please remember though serious my tongue is sometimes placed firmly in cheek for dramatic effect.

There has been a great debate happening over the airwaves of the blogosphere recently. Sparked of by James Shore's post The Decline and Fall of Agile it has gotten to some people declaring the death of agile and others calling for the rejection of the term altogether [link]. It's as if the Nazi party has just announced that the Third Reich was built on Scrum and suddenly everyone is trying to distance themselves: "no we never agreed with that agile stuff, what we were talking about is something completely different".

Around the same time another debate is picking up steam started by Roy Osherove's post Goodbye Mocks, Farewell Stubs. Apparently people find testing too difficult to grok so we need to reject terms like mocks and stubs ('cos though accurate they are apparently confusing) and replace it with another: Fakes. Oh the glaring irony as one side of the movement is rejecting marketing terms because too many people who use it don't know what it means while the other side try to introduce more marketing language to attract the people who don't know what it means.

Uncle Bob has dropped in like Batman at the Jokers party and delivered his direct, powerful blow: "the problem is you're all f*ing lazy". Although I feel that Uncle Bob is much closer to the truth than many other commentators he's not really offering a realistic solution out of the mess.

So what exactly is the problem we've got here? Both of these posts have something in common. James Shore's issue stems from teams picking up words like Scrum and Sprint and forgetting that they have to write decent code as well. Roy Osherove's post stems from the fact that getting teams to even write tests is met with constant failure. Both posts talk about a general lack of engineering skill in IT. In reaction different parties are offering up different solutions but they all fail to address the core issue.

For those jumping the agile ship and getting onto the next coolest speedboat what exactly is that going to prove? Rather than improving the industry it leaves it helpless and sinking. This is a rotten attitude that resolves nothing: when every PHP and VB programmer converts to Ruby what you gonna do then? Oh it's OK Ola's writing Ioke and if that doesn't work we've always go Lisp (they'll never get that). Roy Osherove's solution of lowering barriers to entry is more commendable but will achieve just as little and is guilty of another great crime: dumbing down (though he's spot on about tool support). I don't think the solution to poor engineering skills are to withdraw important technical terms: can you imagine the Bar rebranding legal terms because, y'know Lawyers just find it too difficult to understand this stuff or Doctors calling for less names for the organs 'cos med students these days just can't get the point of having the terms stomach and intestine and they keep operating on the wrong one. Why can't we just call it the food processor? Jay Fields' novel idea is to ask them all to politely leave (50% of them in fact). And if they don't? Well then I guess we'll all get together and go around with a big seal club and sort it out that way (it's what I refer to as "The Great Culling" - there's those Nazi's marching past again).

The real problem, the root cause to all this is simple (and on this most agree especially Uncle Bob and Jay): the gross under valuing of the skills which enable you to do your job. The thing is it's nothing new. It was there before agile and TDD had the impact they do today (they just laughed then). Remember those not so long ago days when people thought the solution to delivering software wasn't skills or focus on quality but getting some glorified secretary to type up several hundred pages of requirements and then handing them to some supposed genius to design everything for the monkeys to punch in? Well we're still there people: it's just they thought the solution to the mess that disaster caused was to do something called iterations, standing up and getting the monkeys to skip around the genius guy wrapping him in his own ribboned UML diagrams chanting "architect, architect, architect".

Nothing's changed, agile or not. The majority of the industry still doesn't value the basic, fundamental skills it takes to write software of acceptable quality. It didn't before and it still doesn't now. Instead it's obsessed with solving the problem by bringing in the right highly paid manager with the right powerpoint presented methodology. Until the industry gets that ain't the way it will drag every shining beacon of light (agile, Ruby whatever) down into Hades with it.

Writing software is about people People! That's what agile and Lean and all their friends tell you again and again. The fundamental principles are about people, not iterations, continuous integration and story boards. Go check out the Agile Manifesto and tell me where you see any of that stuff? This bastard form of agile which only talks about tools and processes is like someone got the manifesto and spun it round (People OVER Process read it Again). The practices and tools are there to actively encourage developers who are skilled, committed and know what they're doing and make them more empowered and productive and ultimately deliver MORE value and success, they are not there to replace them.

So what is the solution? The simple truth is that those of us who understand the problem have got to keep doing a great job, we've got to help those who want to do a great job but aren't sure how to do a great job and we've got help those who don't understand how to do a good job and may never will and may not even want to. Sure it's depressing sometimes, it's frustrating but we can't just give up on the industry and jump away on the next term or simply dumb the whole thing down so the next generation can get it a little more but ultimately still fail to get it.

Agile was never, is never going to be an quick, faultless success forever preserving an eternal purity. Our industry is sick, real sick. It's a beer guzzling, chain smoking, couch potato who's been told by his doctor to eat healthily, give up smoking and booze and get some exercise but instead just swallows the agile pill and hopes that's enough to save his sorry fat arse. And surprise surprise when the casualties start coming in their gonna blame those pills.

We have generation after generation bought up on bad practices and incorrect assumptions (smoking isn't bad for you, exercise gives you heart attacks) and what's worse most of them don't even know how bad things are: they think this is NORMAL (sadly because IT IS), they've adjusted to a certain degree of failure. IT projects are like lifts: sure your pissed off there broken down but your not surprised, you even kinda expected it.

The mess is big and it's gonna take years to sort it out and a lot of hard work. And yes, along the way people are going to buy the agile weight loss pill from some dodgy site on the Internet without seeking professional advice, get it wrong. And why? Because they're desperate!

It was totally delusional to think agile was going to result in everyone suddenly rejecting their bad habits and come crawling on their knees and go XP Kosher. And when that didn't work well there's always the prophesy of the True agile warriors standing in the post-apocolyptic world looking down on the dying as the last breath of those Tragic Lost sigh the now infamous regretful words "we wish we'd read our Domain Driven Designs". Well don't worry because to become agile all you have to do is close your eyes and say "please Kent forgive us our hacks and deliver us not into Waterfall" and mean it, really mean it, and wait, above the mountain there what's that? is it who I think it is? It is: the heavens are open and Martin Fowler is ascending into them.

Let's get real here: developers who have never come across TDD before, who've never experienced it's value first hand, who've spent years doing things a certain way are struggling to grasp the concept and oh sorry that's surprising why? I guess you were doing TDD from that first Hello World in Pascal? And those people who go in and try Scrum for the first time and find they are riddled with technical debt because gave into pressure and didn't invest in quality. Now stand up and be counted all you who never made that mistake.

I'm not saying that we should just let these things go, hold our noses, ignore the smells and step over the shit. Quite the opposite. But we've got to accept that we're not going to walk into a room of professionals and get them to convert overnight (or year or possibly even decade). How many years did it take before doctors accepted germ theory and started washing their hands?

Though there is hope: the most effective weapon we have is success. By being successful and then telling people about why and how we were successful. That's how this whole agile thing started, that's how it built up it's great reputation and that's how it's going to survive and get better. The more success the more people will start to realize that what they're doing now isn't as good as they think. Right now not testing, not caring about quality, high technical debt: that's the norm, that's expected. Keep being successful and people will start asking the others those awkward questions: why does this application crash when my last team were virtually bug free, why does it take a weekend to get a release out when my last team did it in a few minutes? Why does it take six months to implement a new feature when my last team took a week? What do you mean there are ramifications and complications? The more we deliver quality software the less room people will have to worm out of those questions and then the tipping point will come.

Let's not be mistaken, it's going to be hard work: but isn't that the whole point? Writing software is hard, agile doesn't change that and at first TDD certainly doesn't. Yes it's frustrating and somedays you really want to scream and kick in the can but what's the alternative IT ghettos sucking in grads and with no way out?

If, in the years to come, we want to work in a different industry then we've got to take some responsibility for helping create it.

Links for 2008-11-12 [del.icio.us]

2008-11-13T00:00:00-06:00

dotnetopenid - Google Code
OpenID implementation in .NET (C#)

Links for 2008-10-30 [del.icio.us]

2008-10-31T00:00:00-05:00

pdc2008 | Tags | Channel 9

Links for 2008-10-22 [del.icio.us]

2008-10-23T00:00:00-05:00

Links for 2008-09-16 [del.icio.us]

2008-09-17T00:00:00-05:00

The 10 Laws of Cloudonomics - GigaOM
a view on the benefits of Cloud computing

Links for 2008-09-10 [del.icio.us]

2008-09-11T00:00:00-05:00

SOA Web Services Security Consulting & Training www.arctecgroup.net ...

Links for 2008-08-25 [del.icio.us]

2008-08-26T00:00:00-05:00

Latency is Everywhere and it Costs You Sales - How to Crush it | High Scalability
Todd Hoff writes an excellent article on both latency implications as well as several strategies to lower it