March 31, 2006
If you had asked me at the beginning of the year what the best movie of 2006 would be, I would have predicted X-Men 3.  But, I am fairly certain that I was wrong, because so far, V for Vendetta is the best movie of this century. (And also of this millenia? No, I wouldn’t go that far 
Most geek reviews have been positive, one economist was disappointed because it wasn’t as faithful to the graphic novel as he would have liked. Balderdash! I’ve been reading the graphic novel, and it is tedious and hard to follow.
Fair warning – if you are a fan of the current US administration, you probably won’t like this film all that much.
March 30, 2006
Hugh Macleod on planning:
March 29, 2006
Over the last month I’ve had to put OpenLaszlo away, and adopt Flex 2 as my RIA platform.
I would have preferred to stay with Laszlo, but I’ve discovered that the way that Laszlo manages data sources seems fundamentally broken, forcing one to build applications instead of frameworks, and limit reuse. I may be wrong, it may turn out that you can “alias” datasources in a standard way, but I was not able to find it.
But enough about Laszlo. Now it is time to complain about Flex!
Bug: Selection Highlight bar on my DataGrid is stuck at the bottom of the list
Description:
- Create an Array of custom objects – for example, Alerts (your definition) , and make that array the dataprovider for a DataGrid control
- Show it on the screen. Verify that the blue highlight bar is stuck to the bottom element in the list
Resolution:
- In order for the DataGrid or other list-style component to do highlighting properly, the objects in the Array need to implement the IUID interface. Using ObjectProxy, here’s an easy way to do that:
public function addAlert( alert:Alert,
array:ArrayCollection):void
{
array.addItem( new ObjectProxy( alert ));
}
Now, your list should highlight properly.
My RubyOnRails web application (Bellygraph) went Tango Uniform last night. I thought it was related to ongoing maintenance, but when I checked again this morning, it was still dead.
I finally got it working by reverse engineering the configuration of another rails application that did work, and carefully “porting” the config/ directory.
What a week!
March 28, 2006
From the ScrumDevelopment yahoo group, Pascal Roy asks:
Question to the community: Do you feel that using Scrum without any of the agile engineering practices can yield good results?
...
The question I raise (and I shamelessly timed this message with one of Ron’s that more or less discusses this issue) is whether or not you can do iterative development effectively without some of the technical engineering practices.
Here’s my response
In my experience, the most valuable of the agile practices is, without a doubt, doing development in shorter iterations.
Why? Because most people can understand it, it isn't particularly controversial, and yet it still requires the team to think differently about how to organize themselves, how to organize the project and how to quantify what "done" means. Most waterfall development organizations have a QA department, and they are typically fairly good at doing regression testing on previously delivered content.
In my experience, once you have relatively short iterations, the other Scrum practices become more sensible - working software at the end, product backlog, burndown charts, etc. And once you have Scrum, the other agile methods become more attractive - developers start to value unit tests and continuous integration as ways to make it easier to hit the "working software" goal. User stories and acceptance tests are also clearly useful. Onsite customer and pair programming are further refinements to help the team achieve more in the same time, but are also not always feasible.
But you will have a much harder time getting a BDUF team to adopt XP than to incrementally adopt Scrum and grow from there.
From: Maslow on Management.
1) “The better the manager, the more freedom people will feel to express irritation, disagreement.”
2) “Real achievement means inevitably a worthy and virtuous task. To do some idiotic job very well is certainly not real achievement. I like my phrasing, ‘What is not worth doing is not worth doing well.’”
3) “This is an easy medicine for self-esteem: Become a part of something important.”
4) “You can say you are a scientist or you can say you are a business person but if you are truly committed to what you are doing, there’s a point where it becomes your emotional passion. You are always being tested to the core: “Did I do my research correctly?” Is there an integrity to all of what I am doing?”
5) “Creativeness is correlated with the ability to withstand the lack of structure, the lack of future, the lack of predictability of control, the tolerance for ambiguity, for planlessness.”
March 27, 2006
Can giant suits of powered armor be far behind? All we need is some sort of protoculture-based power matrix….
March 26, 2006
Darren Hobbs wrote that he lost his wallet, and he’s struggling to remember what’s in it.
One piece of advice that I read (and followed) a while back was to make a photocopy of the contents of your wallet (all the cards, etc) front and back, and store them seperately, in a secure place.
Obviously in some ways this makes the possibility that someone steals your CC# slightly more likely, but it also gives a nice record of what is there, what numbers to call to report lost/missing cards, and so forth.
If you want to be extra secure, black out the CCV and expiration dates on the photocopies and make a photocopy of that, and destroy the previous photocopy.
March 22, 2006
Jimmy Nilsson asks
SOA == WS?
(Which I interpret as “Does SOA mean Web Services”)
Here’s my answer, in part sponsored by inspired by a talk given by Jeff Schneider of Momentum SI
A service oriented architecture is one where the enterprise applications are each carefully designed to offer remote access APIs to do things. For example, we have been joking around our office (we have a black sense of humor) that we need to add a “Fire the guy who signed this contract” button to our contract analysis application.
That button would need to integrate with the customer’s internal business systems to terminate the employee’s employment, and in general it would look something like this:
- Contact the security systems and tell them “this employee has been terminated”. The security system would disable keycode access, lock out passwords, etc.
- Contact the HR systems and tell them “this employee has been terminated”. The HR system would remove the employee from the insurance plan and send the guy his last check
- Contact the Workflow system and tell them “this employee has been terminated”. The Workflow system would redirect all of his current work to other people.
- Contact Facilities system and tell them “this employee has been terminated”. Facilities sends Guido with a cardboard box to escort the guy out of the building.
Now, in theory, these remote commands would not have to be SOAP/Web Service based. They could be based on CORBA or RMI, or even Sun RPC (yes, I’m that old). But in practice, the CORBA, RMI and RPC interfaces are much harder to use, much harder to guarantee availability on “platform X”, much harder to debug and much harder to proxy.
Think about that last one. The nice thing about SOAP is that it’s XML, a format that isn’t Big-endian or little-endian. You can have any number of intermediate systems between your “fire that guy” button and the thing that does the work, as you can see in this example.
That would be much harder with a CORBA or RMI implementation. Not impossible, and I’m sure there are systems out there that do this.
But they have never caught the imagination of the worlds IT departments the way a Web-Service based SOA has. And so:
SOA ~= WS
(thats “approximately equal”)Â I think the key difference, and the thing that makes SOA ~= WS is that WS is a format that is easy to use, easy to store, share, debug and record, without having to know nearly so much about the overall system.
My previous post brought some confusion over my views of agile development and Model-driven architecture.
When I said “MDA is the wave of the future” I was speaking as if I were James McGovern, trying to be a thought leader.
John Brothers, the author of Indefinite Articles, does not believe MDA is the wave of the future, in my opinion, MDA is just another CASE for F500 organizations to throw money into. But this is not a terribly informed opinion, so don’t take me as a thought leader on MDA.
Some may think I’m being unhelpfully mean with my criticism of Mr. McGovern’s post. So, let’s try a different approach. Using the same basic content that James put together, I’ll demonstrate the difference between leading and following. I’ll indicate where I feel that I deviated from James’ content with italics.
How do we get Ruby into the Enterprise.
I’m a fan of Ruby, and an Enterprise Architect, and I’ve given some thought as to how Ruby might become important in the Enterprise architecture space.
First, the problems:
- Enterprise architects are, by and large, a conservative bunch
- Fortune 500 Enterprises are more focused on legal transparency than performance.
- Ruby’s “enterprise infrastructure” is lacking
- Model-Driven Architecture is taking over
Let’s address how we might be able to solve those problems:
Conservative Enterprise Architects
The key here is critical mass – nothing gets done in F500 enterprise architecture w/out lots of tongues wagging. We need one ore more of the following:
- A large hardware vendor to adopt Ruby as a solution. IBM or HP are obvious choices. This is obviously hard, and largely out of our control. The best way to do this is probably to build Ruby up in small and medium enterprises. OVer time, this will help make it more legitimate and more interesting to build solutions around
- Consulting Agencies (Bearingpoint, Wipro, etc) need to develop a Ruby practice. Thoughtworks is already doing this, and while they are small, they have a lot of press. This is an area where continued success will force the big consultants to take notice.
- Articles about Ruby in the enterprise need to show up in major magazines. This is probably the easiest one – we know that Ruby has some legs, and magazines like to talk about interesting new things.
- Coverage by analysts. Unfortunately, analysts are the classic lemmings – uninterested in new things, because they don’t like having to argue a position. This won’t happen until one or more of the others do.
Transparency over Performance
I bet you didn’t realize this was true, but yes, Fortune 500 companies are forced by Sarbanes-Oxley and other laws to worry much more about complete business transparency and ethics than they are about raw performance. This is not to say that performance isn’t valuable, but it is just not as important as transparency. And don’t forget, as an enterprise architect, I get several calls a day from people who tell me their product will improve productivity. But a product that could improve transparency? That would be very well received! A transparent enterprise architecture is one where every step is monitored, logged and compared to the last for correctness, where alerts are generated when things change in unexpected ways. Essentially, you need to think of your data as prisoners, and your enterprise architecture as the jail that they are forced to live in. If the data escapes, or it goes somewhere its not supposed to, you’re fired. What does this mean for Ruby? Extensive Security Analysis. Extremely accurate and voluminous logging, and a bunch of other things that I won’t get into here.
Enterprise Infrastructure
If your Ruby server goes down, how is that communicated to the operations team? How about detecting dictionary password attacks? What about integration with SNMP or JMX? Those are the kinds of things that enterprise systems need to support. You need books – on how to make Ruby applications monitorable and traceable, written by people with extensive enterprise experience. You need robust toolsets for integrating with enterprise authentication systems, with enterprise monitoring systems. You need development tools that make the already easy mechanisms for producing code in Ruby even easier.
Model-Driven Architecture
Over time, I’ve become a big fan of MDA, and I think it is the wave of the future. If this comes to pass (and I hope it does), then the traditional metrics of “it’s easy to produce code in language X” no longer really apply. However, I think there are some interesting things about Ruby that might make this easier – especially when you look at Rails – techniques that make Ruby-based MDA more robust and flexible to change than other language choices. I feel very strongly that agile development is on the downswing, and MDA is the wave of the future. But that doesn’t mean Ruby can’t keep up. Because Ruby is a programming language, not a development methodology. You may disagree with me, but that’s fine. I can handle a diversity of opinions on this issue without assuming that everyone else is a sellout.
There.. That’s what a Thought Leader writes.
This post by James McGovern on Ruby reminded me of something… oh yes, this:
Leaders respect those who are superior to them and tries to learn something from them;
followers resent those who are superior to them and try to find chinks in their armor.
and James McGovern says: While there are lots of books on Ruby, none of them are good.
A leader says, “There ought to be a better way to do this;”
followers say, “That’s the way it’s always been done here.”
and James McGovern says: For shops that have mature enterprise architecture practices, they simply don’t allow insulting firms to propose architectures for them (most of the others that I don’t quote from his list fall in this category as well)
Leaders feel responsibile for more than their job;
followers say, “I only work here.”
and James McGovern says: Much of the guidance that the enterprises receive come from either big consulting firms such as Accenture, DiamondCluster, Wipro, Bearingpoint and others. If it isn’t on their radar then it probably won’t reach critical mass
A leader works harder than a follower and has more time;
a follower is always “too busy” to do what is necessary.
and James McGovern says: How many enterprise architects do you think that work for Fortune enterprises are actually reading the magazines that to date have discussed Ruby?
A leader goes through a problem;
a follower goes around it and never gets past it.
and James McGovern says: Those same vendors such as Sun, Microsoft, BEA, Oracle, CA, etc simply can’t make money off Ruby. If a business can’t make money off it, why would they even care?
Leaders listen;
followers just wait until it’s their turn to talk.
and James McGovern says: The productivity argument is lame. Do you know how many times my phone rings in a day with some poorly trained sales guy on the other end attempting to sell me something?
A leader works harder than a follower and has more time;
a follower is always “too busy” to do what is necessary.
and James McGovern says: Since Ruby is a new vendor and not represented by existing vendors I already do business with, do you think that I will spend more than three weeks in just negotiating the contract?
A leader says, “I’m good, but not as good as I ought to be;”
a follower says, “I’m not as bad as a lot of other people.”
and James McGovern says: I am one of the biggest supporters of agile methods but I too am not so delusional to know that many of its founders don’t practice transparency.
Note – my thoughts on this have nothing specific to do with Ruby. Ruby is just the symptom. It’s the appalling state that Enterprise Architecture has fallen to – preferring “Let’s not rock the boat” to “Let’s find new ways to make a remarkable enterprise” Are you listening, Sig? Seth? Greg?
(Hat tip: Obie Fernandez)
March 21, 2006
In a great post, Jean Tabaka talks about Risk, Uncertainty and Doubt. I wanted to lay out some specifics with regards to Agile development’s ability to manage RUD.
Risk
There are lots of ways to manage risk. Waltzing with Bears is a great place to start, agile project or no. One of my favorite risk-mitigation techniques is to create a Risk Census, a Risk Forecast and a Risk Burndown chart, and integrate those into the overall project schedule. These help
- Tell us which risks have the highest impact.
- Tell us what the expected overall hit to the project will be from risk (within reason)
- Help us visually see our risks decrease over time
I’ll write more on risks later.
Uncertainty
Spikes in XP, or rapid prototypes as stories in early iterations are ways to manage uncertainty. We (my company) have that right now in a current project, with uncertainty about how to implement a key feature. So I have advocated that we make “proving out” that capability a key story/task for the upcoming iteration.
Doubt
Doubt is probably more appropriately called analysis paralysis. Because there is no good option, people refuse to make a decision, preferring to hope that a good option will come around. One of the key ways to manage doubt is simple leadership – someone who simply says “this may suck, but it sucks less than the other options and we have a schedule to keep”. In agile, this is represented to a significant degree by the time pressure inherent in Iterative development. You can’t afford to “hope” for very long that a better decision will come, so I think that it can force the issue in ways that longer-cycle development does not.
March 17, 2006
I think the most underrated of the benefits of agile software development is the feature- and delivery- focused feedback loop.
The ability to get project feedback in weeks instead of months, using comprehensible, real-world metrics is something that any operational manager should instinctively appreciate. In fact, I suspect that if you were to rename agile development to “feedback-focused development”, we would all find it easier to sell agile software development tools, techniques and services to your average development manager
Why do I think this?  Because a good operational manager understands that feedback and ongoing monitoring is critical to the success of projects and companies. Imagine a surgeon who didn’t bother hooking his patient up to a heart rate and blood pressure monitor – who put her under, started cutting, and only stopped when he noticed that the patient’s skin was turning white and translucent because bloodflow had stopped. Does that sound like a good way to go about performing surgery?
No, of course not. And in software development, the metrics that are meaningfully equivalent to a steady heartrate and a stable blood pressure are the delivery of tested features. Not the documents, describing what the features will do, Not the the delivery of the test plan, representing what the QA team will test once the software is out of devleopment, and certainly not the 80% complete bar on the Gannt chart representing how much of this particular technical element of the feature is done.
“But the documents are important. you wouldn’t want the surgeon to cut without a plan.” Of course a plan is important. Agile development does not neglect planning; on the contrary, it centers the planning around the need for a feedback loop. Because as every operational manager knows, planning is part of the project. if you can’t get meaingful feedback, the planning phase of the project is a black hole, a big question mark in the middle of the project that the manager has no ability to measure or influence. And no operational manager should have to work under those conditions. And neither should anyone else.
March 16, 2006
Welcome to the March 16th, 2006 edition of the Carnival of the Agilists. This is a biweekly roundup of the most interesting and helpful blog posts about agile methodologies, techniques and practices.
New voices wanted
If you write any blog posts that you’d like to see show up in the next carnival, send email to Agilists.Carnival@gmail.com.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Fun
Books, Magazines and More
Next Edition
The next edition will be on March 30th, 2006. If you would like to participate, please send us a link to your post at agilists.carnival@gmail.com. Or, if you prefer, use this handy dandy carnival submission form.
Previous Editions
All previous editions of the Carnival are referenced at the Agile Alliance website
Want to help?
If you’d like to join the carnival, and add your own take on the last two weeks in agility,
let us know!
March 15, 2006
After much struggle and more than a reasonable amount of shouting “This is exactly what everyone else did, why won’t you do it too?” at my .htaccess file, I have successfully (it appears) migrated my RSS feeds to WordPress from Movable Type.
However, it was a complete hack. Â (more…)
March 14, 2006
With any luck, Bloglines et al will be able to read the new feeds with no changes. Crossing my fingers!
So you’re desperate for old Indefinite Articles? Well, you can read them, albeit in a horrifyingly painful presenation format at http://www.undefined.com/ia2/
I’ve set up a new blog using WordPress, with a new theme. Now, all I have to do is get the RSS feeds setup properly and I should be up and running.