This article fascinates me. The author presents what he himself describes as a “five point star”, then asks people how many points there are. The most common answer is not five!
Gojko Adzic » How many points are there in a five-point star?
For the most common answer to be 10, there must have been some other context, perhaps implicit in the presentation leading up to the question, or in the selection of people to ask. Unfortunately, this detail is not very obvious in the article.
Still a very interesting point about communication of requirements, though!
Over the Christmas break I have been indulging my passion for all things Doctor Who. In particular, I have been reading some Doctor Who novels (largely featuring the tenth Doctor), and listening to some Big Finish audio plays (largely featuring the fifth, sixth, seventh and eighth Doctors.) Working out how they fit together has been a bit of a headache, but now I have found a Wikipedia page which attempts to weave all known Doctor Who stories into something approximating a consistent sequence.
Doctor Who story chronology – Wikipedia, the free encyclopedia
As the tenth Doctor would say: Brilliant!
From an SOA architectural view, Business Process Management and workflow orchestration seems an obvious component of a large system. However, when I see this idea moved wholesale into the world of REST, I worry that a significant point has been missed.
InfoQ: IBM’s BPM Zero Project: RESTful Worflow Management
The part of BPEL workflow orchestration which makes sense when used with traditional services (presented via SOAP or other RPC mechanisms) is the connecting together of displarate executable chunks into a larger executable chunk. In effect, BPEL used as an over-arching programming language.
The point that is missed when this approach is applied to REST is that REST is not about executable services, but about resources. A REST-style of over-arching connection would somehow represent disparate resources as a larger resource. This is not at all what BPEL orchestration does.
The practical upshot of this is that SOA workflow management can only work with REST resources which may also be considered as executable services. While such things do exist, they are an unusual and very rare subset of REST. Attempting to integrate REST resources using BPEL typically leads to one of three outcomes: (1) the integration is limited to those resources which are also services, and thus is so limited as to be hardly useful. (2) useful resources are converted or wrapped to appear as executable services, defeating the point of REST. (3) The project is abandoned as impossible, or simply fails.
As a simple “litmus test” for whether you are making effective and proper use of REST: Will your application still work if all the collaborating “services” are replaced by simple files or static web pages? If not, then you need to work harder at understanding REST.
Good solid tips for getting the best out a retrospective (and they are also useful for meetings in general).
Column info : Five Tips for Retrospective Leaders and Meeting Moderators
This is an interesting idea. It’s common for agile techniques to be defined by their benefits to the business, but there is often a benefit to the development of the individual people involved in the agile process, too.
InfoQ: How Agile Benefits the Individual
Nice article on some ways to help achieve an effective llife/work balance
Paranoid Engineering: How to be a good specialist and still have a life
Despite some concerns for the direction of the term, I consider myself an “agile” software developer. Recently Ivar Jacobson presented a conference session during which he discussed the idea of “smart” as some sort of successor to agile.
Smart = Agile++ by Ivar Jacobson
From the above summary there seem to have been some good points – the issue of the education system not actually covering the attitudes and skills necessary for software development, even in supposedly appropriate courses is one I have ranted about many times.
From time to time I have a burst of interaction with twitter. However, the single-site nature of the basic twitter user interface means I often forget to visit the site, and I certainly do not want to receive a SMS text message for every twitter update.
It seems a solution may be at hand. A growing ecosystem of assistance applications is surrounding twitter, offering interesting uses and alternative ways to filter the flood of messages.
Filtering Twitter, One Tweet at a Time – Bits Blog – NYTimes.com
I use Test-driven Development (TDD) all the time. Although my immediate work colleagues have “bought in” to the idea, I sometimes find my self explaining about it to other people in other situations. A common question is whether the extra effort of writing all those tests slows down the overall development process. Mark Needham has an article on this very question.
TDD: Does it make you slower? at Mark Needham
A solid, though relatively brief article on the issues facing distributed development.
InfoQ: Distribute Development and the Quality Will Suffer
QCon looks like an interesting conference. I can’t justify spending over £1000 (plus travel and accommodation) for it, though. How is it that conferences can charge so much when so much information is available for free on the web?
InfoQ: QCon London Update: 3 Months Away, Tony Hoare, Martin Fowler, Dion Hinchcliffe
Sometimes I think I am becoming a cracked record with my intention to seriously evaluate the various “cloud computing” offerings, but with the news that Amazon have opened their SimpleDB service to the public I reckon I would be a fool to do anything else.
InfoQ: Amazon’s SimpleDB Enters Public Beta
Maybe I should look to do something like this myself – Mark Levison lists (three takes on) his top ten posts of the year.
Notes from a Tool User: Top Ten of 2008
I have read a lot of faux-REST APIs recently, which are essentially just HTTP/XML or HTTP/JSON remote services, and still need a client to be pre-built with specialist knowledge of URI structure. “Proper” REST allows a server to change its URIs however and whenever it likes, with client applications seamlessly adapting to the change.
InfoQ has published an excellent article describing an approach to building fully self-describing REST interfaces.
InfoQ: Describing RESTful Applications
I still think more work is needed, though, particularly in the area of content types. The suggestion of application/blah.whatever+xml as per RFC 3023 is certainly better than an unadorned text/xml, but still does not provide the flexibility for client applications to sensibly handle new, yet similar, content types. In particular that proposal is limited to XML, with no equivalent for JSON or other data description formats.
Alternative approaches such as text/xml/blah/whatever might allow a more general support. In this example, transport and storage responsibilities might only care that it is essentially a textual format (something which is worryingly implicit in application/blah.whatever+xml), while parsing components might only care that it is text/xml, and so on. There is then the possibility for further information to be encoded in the content type. Consider a type such text/xml/link@href/whatever, which might indicate a textual format, parsable as XML, in which relationship URIs are indicated as a link element with an href attribute, and so on.
While compelling, such an approach could easily lead to fragility, though. Such a representation implies that the range of available content types is a strict single-inheritance tree ontology, with all the familiar problems
that entails.
Definitely an area for further research.
A very interesting post from Gojko Adzic, which seems to indicate that running a quality IT department is more important than aligning the goals of the IT work with other business objectives.
Gojko Adzic » Doing the wrong thing right is better than doing the right thing wrong
A neat article, even though some people don’t seem to see the point of it. For me it’s a useful summary of some potential application issues around machine-machine email communication.
InfoQ: Application Integration Through Mail Servers
A brilliant list of 100 simple things to do to get the most out of your brain. I’m sure we all do some of these, but likewise, I’m sure that each person could probably benefit from doing some different ones as well.
100 Terrific Mindhacks to Make the Most of Your Brain – Find Schools Online.com
I have noticed this phenomenon during our “planning poker” estimation meetings, and to some extent in retrospectives and other meetings about iterations, planning and progress. Each time a meeting is held, the number of attendees increases slightly, and the meeting (sometimes imperceptibly, but the cumulative effect is there) slows down. This slowdown leads to a perceived idea that if only we had more stakeholders in the room, we could get more answers more quickly, so more people are invited. And so it gets worse.
Chris Johnston » Of kickoffs and walk throughs
Is this a general curse of agile processes, or is it a particular anti-pattern or failure mode which can be avoided?
There are a lot of things to like about the Lean movement and the Toyota production system, but I worry that blanket application of their principles to software development may be misguided. Just as with other metaphors used to build a mental model, the metaphor of software development as a factory has big holes in it.
This becomes particularly apparent when considering the concept of defects. In a factory the job is to produce output in large quantities, all of which is consistent with an initial design. From this premise it is easy to understand that any difference from the initial archetype is a defect, which means that the factory process is not working correctly and needs to be fixed.
In software development, the job is not to produce multiple identical things, but to produce new things which did not exist before. From this premise it follows that there is no definitive archetype against which to measure differences. Sure, producing identical copies of software for sale or distribution is like a factory, but typically that process is almost trivial, requiring not much more than a “copy” command.
When developing software we sometimes find ourselves in the uncomfortable situation of not knowing whether something is a defect or not. All we know is that it is different from some expectation, but any particular difference may be a defect or it may be an improvement.
Testing: What is a defect? at Mark Needham
In an agile process, what is a defect?
Can anyone point me at any resources on Toyota’s approach to product development, rather than the familiar material on their approach to factory production?
We have a large project wall, on which paper/card stories, bugs and tasks progress from submitted through to tested. This is great for a quick view of state, but the physical movement of tokens does not help in tracking and analysing progress.
Akshay Dhavle suggests the use of “finger charts” to get a better and more useful of project progress, in particular to help identify time-related problems.
Business Analysis: Finger Charts