A challenge presented to developers when designing smart client apps includes keeping the solution's assemblies, which must communicate at some point with one another, as loosely coupled as practically possible.
Reaching this goal will greatly increase the "intelligence" of the software tool as the capability to version your app increases. The "smart" in smart client application design, among other things, is the capability to keep the code base as feature-rich as possible, with minimal impact to both the developer tasked with creating and managing the source (relatively speaking), as well as the end user consuming the updates on the client.
At the same time, designing strongly typed objects can reduce the headache of building and managing over time the interaction these objects have with the user interface layer of the application.
How do you design components that need to communicate with each other, while removing the constant dependency inherent with early bound objects in a way that is repeatable, and easy to manage? The following image illustrates this pattern, with a description below.
A common smell that is often detected in teams trying to become more agile is more and more stories/backlog items incomplete at the end of the iteration. There are a couple of different reasons this might happen, but the one I'm interested in today can be detected by the claim "I finished my tasks". The clear implication is that "I got my stuff done, but someone else didn't".
A little additional research usually shows that people are waiting for people with some kind of specialization such as database, QA, UI, or any other skill that isn't widely distributed among the team. As an agile team this is where specialization gets in the way. In a more traditional project the measure of delivery is the task, however, in agile projects the measure of delivery of working features. Specialist typically don't deliver working features, thus the problem.
Note I am not saying that specializations aren't needed, but they do need to be balanced with other needs that help deliver features. Agile teams tend towards people who are "generalizing specialists" rather than generalists or specialists. Scott Ambler has a good discussion in this article as does Mishkin.
So the question becomes "what to do about it?" Well, it depends (said the consultant...).
Are your specialists on your team or part of someone else's?
Are they part of a separate group dedicated to their specialty (functional grouping)? Typical examples of this are dedicated DBAs and separate QA organizations. In general agile teams want to have all the skills necessary to be successful as full time team members. Of course this is not always possible due to organizational constraints or because the specialist is from an outside organization (contractor). Scott Ambler recommends explicitly scheduling tasks that involve external groups. I think this great advise and can clearly assist in overall project transparency. You are making your project plans publicly visible aren't you?
Are the specialists available to your team?
If the specialists are not on your team are they available when you need them? Or is it more like Baskins-Robins where you take a number and they will get to you when they are done with everyone else. Or have the other projects in your organization slipped their dates and now overlapping with yours so that the specialists are double or triple booked?
The first thing to do is to try and get your organization to work with you, rather than against you. How you do this is dependent on your organization and may take longer than your project can stand. However, in the long term this is the best solution.
Assuming the organization can't or won't work with you there are a few options. You can go outside your organization to contractors, consultants, etc. This may carry some political risk with it so you'll have to balance the politics with the ability to get things done.
If you don't have funds to go outside your organization think about training the team so they are more independent from the specialists. This may not be as quick a fix as you need, but it can get you there sooner than you might otherwise. Plus it has the benefit of removing you dependence on the specialists (as well as giving your team new skills).
A more radical idea is to look for ways to eliminate the need for the specialized knowledge altogether. This won't work in all cases, but a little creativity could buy you a little time and possibly a lot. Think about things like database needs. What if you designed you system such that it didn't need a database, or at least was independent of the database. Then you could make use of the DBA when they were available, but it wouldn't impact the progress otherwise on your project.
Is your team pairing with the specialists?
When the specialists are working on your project is someone from your team pairing (or at least working with) that specialist? Or is the specialist isolated from your team (even if just in a separate cube)? Your team needs to start absorbing this specialization as well as decreasing the feedback loop on what the specialist is working on. For example if your performance testing group just takes documents as input and sends back performance data after a week without any intervening interaction you've lost valuable time if there was an early problem that you could have corrected the first day.
Agile principles at work
So which agile principles are at work in correcting this smell?
The Carnival of meme has hit the agile blog world. Check out the first edition.
I've been quiet recently, but busy. Last spring I moved from the consulting world back into "regular" employment where I manage a couple of product teams and internally consult on iterative software development and agile approaches. Since starting here I have run across a number of "Process Smells" that I encountered in my coaching/consulting days that are begging to be written down. So here I go.
Process Smells are those little and big things that get in the way of achieving your goals. The "Smells" name comes from Martin Fowler's reference to "Code Smells" in his book Refactoring. It seems to be a great metaphor since often times you know something is wrong, you just can't put your finger on it. It just smells wrong.
Most of my smells will be related to transforming a team to an agile approach as well as keeping a team agile.
Dustin, one of my co-workers, ran into a problem accessing
the "alt" attribute on image buttons using Watir and discovered a useful
Who knows if this will ever be useful to anyone else, but I've been
trying to work with imageButtons, which have alt tags. In HTML they render as
<input type="image".../> I wanted to
access the alt tag of the image. ie.contains_text wouldn't find it for me.
Only image objects in watir have any knowledge of alt tags. And
unfortunately, watir recognizes imageButtons, not as images, but as
buttons.there is almost no documentation that covers this, but I found that even
though these are buttons, you can use image methods to manipulate these
'buttons'. For example, you can get the object with:
- button = $ie.button(:alt, "This is the alt
text...") *alt is only exposed for images, but works for
imageButtons.And you can manipulate the buttons with image
methods, such as:
I'll be in London next week (6/19-6/24) so if anyone wants to get together in the evening drop me a line.
Last week I had the following email exchange with Andy Oram, a highly respected book publisher and author at O'Reilly, specializing in Open Source technologies, and the movement in general. I initiated the exchange after a conversation with Keith Steele, who works on the Pisces project at BPA, concerning the word "Commodity", and its usage with Open Source software. I think you will find it interesting....
My initial email:
ne who is genuinely interested in Open Source software, and the movement, but comes from a Microsoft background, I have a simple question for you that hopefully you can help me with.
The dictionary defines the word, "commodity" as such:
1. Something useful that can be turned to commercial or other advantage: “Left-handed, power-hitting third basemen are a rare commodity in the big leagues” (Steve Guiremand).
2. An article of trade or commerce, especially an agricultural or mining product that can be processed and resold.
3. Advantage; benefit. Obsolete. A quantity of goods
Can you explain why this word is now accepted in the lexicon of the Open Source movement? For example, in your article, "Linux becomes a commodity at LinuxWorld" http://www.oreillynet.com/pub/wlg/3614 your first sentence reads, "Perhaps the clearest indication that operating systems are becoming a commodity".
If the modus operandi of the movement is collaboration, sharing, and free software, than why is this word, that is normally used to describe Capitalistic vehicles for wealth generation, being used in this way?Sincerely,
That's a really great question! Thanks for writing and pointing out the
odd shift in meaning. When I look up "commoditization" on Wikipedia (a
great example of my meaning of the term, commoditizing encyclopedia
content) I get the formal definition you mentioned in your mail. But
when I look up "commodity," I see some material that supports the common
use in the open source community. Here's a relevant excerpt:
In the original and simplified sense, commodities were things of value,
of uniform quality, that were produced in large quantities by many
different producers; the items from each different producer are
considered equivalent. It is the contract and this underlying standard
that define the commodity, not any quality inherent in the product. One
can reasonably say that food commodities, for example, are defined by
the fact that they substitute for each other in recipes, and that one
can use the food without having to look at it too closely.
Wheat is an example. Wheat from many different farms is pooled.
Generally, it is all traded at the same price; wheat from Joe's farm is
not differentiated from wheat from Jane's farm. Some uniform standard of
quality must necessarily be assumed.
I think somebody took the original meaning (which you laid out in your
email) and took a bit of a flight of fancy to come up with the more
Open source didn't start it. For a long time I've heard phrases such as,
"IBM-compatible PCs became a commodity." That is, all companies were
pretty much the same and it didn't matter to consumers where they
bought, except for subtle differences in support. And that was credited
with making Microsoft software so valuable, and making it the focus of
changes in the computer field.
And I've heard it said that this kind of "commoditization" of the PC
lowered the prices so much that for the first time, a few years ago, the
price of the software became significant. So companies started to wonder
how they could cut down software license fees--perhaps a boost to open
or the quick and enlightening response to my inquiry.
As I looked around the net some more I came across an article that described software "Commoditization" in a similar way.
Here's the relevant excerpt:
Open source is helping turn significant chunks of the IT infrastructure into commodities by offering alternatives to proprietary software. (See "Enterprise Ready," left, for a list of these tested open-source applications.) This is software as corn or wheat. As the products become indistinguishable, buyers will choose the cheapest, most reliable supplier they can find-and it's hard to beat open source on price.
Andy's last response:
I agree with you that it's much harder to marshal a lot of volunteers
(or willing vendors) in narrow, specialized spaces. What I wonder is
whether innovation can take place in open source too. On small things,
the proprietary vendors seem to take the lead and do a better job. But
on world-changing ideas such as the Internet and the Web, open source
was there first.
My final response:
The question I have is how far "up the stack" can "Commodified Software" get?
|<< <||> >>|