Pages: 1 ... 6 7 8 ...9 ... 11 ...13 ...14 15 16 ... 19

10/08/05

  05:13:01 pm, by Kirk   , 173 words  
Categories: .NET

On smart clients, adhesion, and strong objects

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.

EventBroker

09/30/05

  12:31:45 pm, by   , 774 words  
Categories: Agile, Agile Process Smells

Process Smells: Waiting on Specialists

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?

  • Generalizing specialists
  • Whole team commitment to completing features
  • Do the simplest thing
  • Work together
  • Reduce feedback loops
  09:03:19 am, by   , 15 words  
Categories: Agile

Carnival Of The Agilists - 09/29/05

The Carnival of meme has hit the agile blog world. Check out the first edition.

09/27/05

  04:21:46 pm, by   , 149 words  
Categories: Agile, Agile Process Smells

Process Smells: Introduction

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.

Enjoy.

09/20/05

  01:33:07 pm, by   , 161 words  
Categories: Testing

Watir Hint for Working with ImageButtons

Dustin, one of my co-workers, ran into a problem accessing
the "alt" attribute on image buttons using Watir and discovered a useful
trick:

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:

    07/23/05

      05:27:45 pm, by   , 0 words  
    Categories: Events

    Wayne Allen to Present TDD at Portland OR Code Camp

    07/21/05

      05:24:10 pm, by   , 17 words  
    Categories: Agile, Misc

    Presenting TDD at Code Camp 2005 in Portland, OR

    I'll be presenting a session on TDD at the 2005 Portland, OR Code Camp on July 23 at 11:15am.

    06/20/05

      05:28:56 pm, by   , 0 words  
    Categories: Events

    Wayne Allen to Present at Gilb Symposium in London

    06/14/05

      04:40:17 pm, by   , 20 words  
    Categories: Misc

    London Bound

    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.

    05/29/05

      05:33:55 pm, by Kirk   , 1057 words  
    Categories: Misc, Open Source

    Open Source software as a Commodity? An exchange with an expert

    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:

    Andy

    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,
    Kirk Miller

    Andy's Response:

    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
    controversial meaning.

    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
    source.

    So, in short, the term seems to have been jerked around a lot to point
    to a socio-economic phenomenon. I think the phenomenon is real, but it
    might be too bad that a good term had to be reused to describe it.

    My Response:

    Andy

    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.

    That makes sense, but I think the term is misleading for the following reason: Some software is surely heading for, or has already become, homogenous.. or, "indistinguishable" from one competitor's version to the next. Web servers come readily to mind. In this respect, the excerpt's first sentence is accurate. However, further "up the stack", as I've also read recently, referring to the applications that reside on top of "Commoditized" software, it seems to me that the tools and applications will always remain far too specific in what they are doing, and what problems that are resolving, to become generic. In this sense, proprietary vendors will probably always remain one step (or more) ahead of the process of commoditizing that, perhaps, will continue to take place.

    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.

    Andy

    My final response:

    The question I have is how far "up the stack" can "Commodified Software" get?

    It seems to me that the more Commodification takes place in software, the better case Open Source advocates can make to the business community that Open Source software makes economic sense to adopt. However, I fear that, in the attempt to relegate an ever-increasing range of applications as "homogenized.. Commoditized" with the goal of expanding the presence of Open Source, what could lose out is functional innovation...what is also known as strategic advantage that makes one product shine when compared to its cousins. Ultimately, even if Open Source wins out in the end, the compromises that victory required might have deleterious effects to the entire industry.

    1 ... 6 7 8 ...9 ... 11 ...13 ...14 15 16 ... 19

    March 2024
    Mon Tue Wed Thu Fri Sat Sun
            1 2 3
    4 5 6 7 8 9 10
    11 12 13 14 15 16 17
    18 19 20 21 22 23 24
    25 26 27 28 29 30 31
     << <   > >>

    Guild Blogs

    Search

      XML Feeds

    Real Time Web Analytics
    powered by b2evolution CMS