Archives

Archives / 2004 / July
  • Another solution to spam

    My previous solution to spam detailed in another entry was based upon how I, as a service-oriented technical architect, naturally approach such problems.  Having had a bit of a think about it, and a bit of enlightenment about how money isn't the only currency (CPU time, etc. also are in a way), I've come up with a new zero-infrastructure solution:

  • Energy expenditure signatures

    In an ideal world, the effort being expended at any point in a project will be the same as at any other point - the team involved would never be overstretched or under utilised, always working at an optimal pace.  One goal of any software development methodology should be to achieve this burn-rate equilibrium.

  • A Solution to Spam

    I've had a constant e-mail address since 1998 or so.  I've never received more than five to ten real mails a day to that account as I've had others at the same time - whether at University, at work, on Hotmail, and so on.  I've got to keep this account because of all the books and articles that are out there have it as my contact details in the biography, and so on.  The problem is, the junk mail is now dwarfing the real mail (I now only receive one or two real mails a week to that account).  Here are a few statistics:

  • Anti-Patterns of Architecture

    There are many books and articles on architectural patterns available. Despite these, systems with bad architecture seem far more endemic than good architecture. Here's a quick taxonomy of the anti-patterns of architecture that I've spotted in systems over the last couple of years:

  • What is Service Oriented Architecture (SOA) Really

    I've had a number of conversations with people since SOA became the vaunted architecture of the future.  Everybody that I've come across has slightly different thoughts on what it means, and many are in the "it's exposing objects as Web services" camp.  I'm really comfortable with what I think it is now, so maybe this'll help clarify it for a few people...

  • Thoughts from 1998

    Back in 1998 I wrote a few "articlettes" similar in length to those I'm doing for my blog now.  They were each put as a page on my website, which at the time was promoting my skills around web-design and Internet technologies.  I was refreshing a bit of content on my site over the weekend and spotted one of them from around March '98 on my predictions about the .COM boom.  I thought it might be worth posting up here for interest, so here it is, unedited in any way other than to tidy up a couple of typos:

  • Outsourcing the Future

    In almost all of companies that I've worked, the issue of "who does development on the new technology" has arisen.  In a large number of cases, the work has been outsourced to contractors, leaving internal developers disenfranchised and resentful.  The general developer opinion has been that the managers don't care, that they were brought in for their skills and have been left to rot since, and that there's a lack of belief in their abilities.

  • Post-it notes and planning tools

    As other projects have been relatively quiet, a lot of my effort from 9-5 over this last week has been on XP StoryStudio - an XP planning tool that we've been developing at work, and should be open-sourcing shortly.  It's the second version of the tool, with the first already used internally.  So, this version's nearing completion - I've been adding a few reporting statistics such as story-point burndown rate, making it know when stories and iterations should be in-progress/complete based on the tasks within them, etc.  I've got through about 13 stories this week along the lines of "As a developer, I'd like a story to be set to be in progress when I mark a task within it as in progress".

  • Generations of software design paradigm (or "what comes after SOA")

    As time progresses, software development becomes a more mature discipline.  With each "new generation" comes a solution to another problem that was found.  For instance, the generation of C++, Visual Basic, Delphi, and other similar technologies in the early 90s was the generation of Object Orientation - trying to model real world artefacts with their digital equivalents.  Each new generation takes what was provided by the previous generation and builds upon it through abstraction, solving another problem (along with introducing efficiency developer gains), bringing the development paradigm closer to the real-world problem domain:

  • Virtual Evolution via TDD

    Whilst falling asleep last night I had a thought - the suite of tests in a Test Driven Development project actually forms a fitness function, one that determines how fit-for-purpose the system they're associated with is.

  • Good Architecture == Bad Architecture

    Today, I spent some time questioning what makes companies decide to migrate to new architectures.  The conclusion that I came to was based upon the "architectural change is a tax to pay/avoid" mantra that I think Business has.  Basically, change is often only approved where necessary or with zero cost/risk; if the current architecture is seen as failing now, can be shown to fail in the near future, or change has no real cost/risk associated with it then there is a good reason to change or little reason to avoid change.  If the risk of staying on the current architecture vs. migrating can't be shown to be a really clear call, then change is less likely to be approved.  This is where I've found a problem to exist:

  • XML - Just another TLA?

    XML.  Possibly the most highly vaunted TLA of the 21st century thus far.  Religious wars continue on value-vs-attribute - even I'll join in on that argument given half a chance.  Systems everywhere are burning CSV logs on pyres in the race for XML as an output format.  Relational databases are being contorted to support the storage and querying of this data.  At this rate, the angle bracket will outstrip the full-stop as the most commonly used punctuation mark by the end of 2006.  (OK, so I made the last one up, but it wouldn't surprise me)

  • XML Explicit

    On various MS code help forums I've seen dozens of posts along the lines of "How do I get a root tag in an FOR XML EXPLICIT statement.  There have been numerous responses:
    Do three SELECTs, with a "SELECT '<root>' FROM [Foo]" as the first one
    Read the data back into one string, and append the opening/closing tag
    Etc. etc.

  • Metaphor and Analogy

    In general, humans learn from experience.  Either directly, or indirectly through the experience of others.  So, we refer to previous examples of similar patterns and behaviours to explain new ones that occur.  The benefits of this are clear - it allows us to more readily understand and convey concepts without the need for a new frame of reference.  This is the use of metaphor.

  • Standardisation of Web Services

    Now that the Service Oriented Architecture (SOA) bandwagon is in full swing, and real-world implementations are starting to proliferate,
    a physical crack is starting to appear in the veneer...  the (lack of) homogeneity of data.  It is a key area of focus in many systems and enterprises.  How many different definitions of a customer do you have?  How does that differ from your supplier's definition of a customer?  How do you reconcile these differences without having mapping functions at every level that create lossy-systems?

  • Worst Case Architecture

    I've spotted a (worrying) trend amongst architects over the last couple of years.  Whenever designing a new system, there's a tendency to spot the potential for a change in requirements in the future that would negatively impact the system, then design that in from the start.  This is what I've termed "worst case architecture".  Where rather than designing a system that is either inherently flexible or cheap enough that throwing it away isn't a great loss, the architect becomes a seer, predicting what s/he thinks would have the most costly impact, and designing it in from the start.  This is the cause of several problems: