CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Ian Cooper [MVP]

January 2008 - Posts

  • Keeping in touch with Altnetconf UK

    Those of you who can't attend Altnetconf UK may still want to keep in touch with what we are up to during the day. We have three mechanisms to help you do that:

    • First, Dave Verwer, has set up a newsriver for us where you will be able to pick up AltNetUK tagged posts.
    • Second, we intend to update a wiki with session summaries on the day. We are thinking of using some pages on altnetpedia to do this.
    • Third, we hope to have some video of the proceedings, after the event. 

    For those of you who are registered to attend, I'm looking forward to seeing you at Conchango, our host's, offices on Friday night.

     

  • Altnetconf UK: Second Batch of Tickets

     Get 'em while you can.  We have also opened a google group for attendees so that you can keep track of timings, etc. You should get an invite when you register.

     

     

  • C# Futures, Diminishing Returns, and the Scala Parachute

     A while ago Jeremy Miller posted about C# futures. In response to his own thoughts on what might be required, including mixins for example, he suggested that c# may be approaching the same point, that further changes post C# 3.0 might push it over the point of diminishing returns.

    There is an experience of diminishing returns on languages and frameworks. At a certain point adding new ideas to a language increases its complexity so much that the productivity benefits form the new features are outweighed for anyone coming in to the language by the cost of learning its idiosyncrasies. Part of the issue here is boiling frogs problem. Those of us using the language do not notice the complexity burden increasing, because we only have to cope with understanding the additions, but for someone arriving fresh at the language, it's like jumping into boiling water. It's much like a long-running TV show, where new audiences cannot grasp all the references to previous shows and so never start watching. In the end the networks cancel the show, because it cannot attract new viewers and the existing ones are not being replaced as they fade away. Our hit show plays out as re-runs. MFC became more and more complex with time, especially after it shifted to include support for OLE, to the point where it became too hard for many people to start developing with it, so now, for application developers at least, it tends to be legacy code.

    It looks as though, for Bruce Eckel at least, Java has passed the point of diminishing returns.

    What is interesting beyond the realization that the Rubicon may have been crossed is not some kind of CLR vs. JVM triumphalism but the assertion that new features belong in new languages, designed to be that way from the ground up. Bruce notes that for some developers the choice is to leave Java for a new language and interestingly its not Ruby, but Scala. Ignoring the, Ruby is no longer cool, Scala is, message that has somewhat clouded the debate, the interesting part of Scala (which has a .NET implementation) is that it may be an easier transition for Java developers than the switch to Ruby, especially those who may prefer a statically typed language over a dynamic one. Of course what is easy for Java developers is also easy for C# developers.

    Maybe it is possible that rather than focusing on changes to C# the C# team should pick up on the goals of Scala, to incorporate functional language features into a new language that is more familiar to C# developers than Ruby, but at the same time is designed from the ground up to incorporate the functional programming features that otherwise might be shoehorned into C#.

  • Altnetconf UK: First release of tickets sold out

    The first release of tickets for the UK altnetconf were made available yesterday and were snapped up yesterday. Great to see that there is still enough interest in the alt.net meme, despite the increase in noise over signal on some of the mailing lists of late.

     We will release another batch soon. Watch this space.

  • Architects: Back to the future?

    What does it mean to be an Architect?
    Last year I attended Microsoft's Architect Insight Conference here in the UK. One interesting aspect to the conference was asking the community to try and define what an architect was. It proved impossible. Indeed the term architect has become so difficult to pin down in IT that we now qualify it with what kind of architect we are talking about: solution, technical, business etc.

    Why is this a problem? The reason for the topic being raised at the conference was that if we cannot agree what an architect is, how can we identify what skills an architect should have. Without an agreement on the skill set of an architect then it becomes hard to assess people's fitness to be an architect, offer training to those who wish to be an architect, or hire someone as an architect and know what you should be getting.

    Indeed, the agile community, has had heated debates around the role of architects in an environment where big-design up front has been devalued in favor of emergent design. Martin Fowler famously questioned Who Needs and Architect? But again, the debate is to some extent around the meaning of the job. The criticism of the architect as bottleneck is around a a job description where the architect as sole authority of design vision. Martin recognizes the value of an architect who is able to pass on experience to the team: a coach and troubleshooter. Jeremy also talks about the issue here, including raising the issue of what happens when XP teams do no upfront thinking (b.t.w. I don't think that Jeremy experienced a good reading of XP here, and its certainly not true of other Agile methodologies like Crystal to suggest that there is no design up front, indeed along with McConnell I believe that the alternative is enough-design-up-front (ENUF) ). At the same time other agile practitioners are actively talking about the role of architects in agile.

    Again the dispute is around terminology. Redefine what an architect is for an agile project and the role has meaning again.

    About the only part of this conversation where any agreement is ever generated is that most people identify architects as a leadership role, and qualification for that role comes from experience of delivering solutions.

    My conclusion would be that the term architect cannot be said to be anything less or more than that recognition of seniority and experience. That is not intended to devalue the people who call themselves architects, but to point out that, on a comparison basis, it means nothing other than this.

    A history of architects

    An interesting aspect of this is that our use of the term architect comes from the construction industry, where a formalized program of training exists. But it was not always so.

    Listening to BBC Radio 4 over the holidays I chanced upon an interesting fact - the history of the term architect. Pre-renaissance, architecture within the building trade did not exist as a separate discipline, instead an architect was simply a title given to a master of a craft, who was recognized for being able to lead a large project. Doing some research via Google, we find the following illuminating analysis from Dana Arnold in Reading Architectural History:

    "the medieval architect was a master craftsman (usually a mason or carpenter by trade), one who could build as well as design, or at least 'one trained in the craft even if he had ceased to ply his axe and chisel'.

    So to the medieval mind, being a master of a technical craft (one who has been accepted by his peers as a master of a craft through presentation of a master piece) was the key step to becoming an architect. To become a master, you had to put in your time - experience, as we have identified, was the key. In The Building of Renaissance Florence Richard Goldthwaite says that:

    "After serving as an apprentice for four to five years and a journeyman for at least one more, he gained his status as a master of his craft...nurtured by instruction from the men he trained with"

    The role of the medieval architect was often hands on. Arnold again:

    "The medieval architect...a craftsmen by training...frequently acted as one of the executants on one of the buildings he himself designed."

    Not only is he hands on, like the agile architect, but we also learn from Arnold that the great Gothic cathedrals of Europe were built, not with BDUF, but with ENUF:

    "That he was capable of envisaging a building as a whole we cannot doubt...but in the middle ages the process of design and construction were much more linked than is the case today. Much more was left to be worked out on the spot than is normal in modern architectural practice, and even major churches were sometimes begun without any clear idea how they were to be completed."

    According to Arnold the medieval 'architect' was distinguished from his peers by a knowledge of patterns that provided him with the knowledge to deliver the building without the need for up-front design.

    The medieval architect was also master of works, his role included team lead and project management responsibilities. Goldthwaite says that:

    "a mason could operate as an architect only if he became head of a works staff. ...he had to prove himself also as an administrator and supervisor who could be responsible for procuring materials and equipment, hiring and supervising workers, and, in general, directing all the technical operations of the construction enterprise".

    But even then the word architect, associated with artistic production, was rarely used, instead the master was simply the head of works. Architecture, with its artistic vision was to come later, post-Renaissance.

    Applying this to our own industry we might worry less about the journey to become an architect, but the journey to become a master. Instead of Mort, Elvis, and Einstein, we might begin to think about apprentice, journeyman and master with the graduation judged by experience and peer review of our work. Architects would come from the craft and have served their time as apprentice and journeyman, and have, during their journeyman years picked up the knowledge of patterns that would enable them to build new works in an ENUF style. To be an 'architect' instead of just a master would become taking on the role of 'head of works' for a project responsible design, recruitment, supervision, and direction of technical operations.

    It may be that we need to go back, to go forwards, embrace the craft roots of our profession to find what 'architects' should do and re-embrace notions of mastery at a formal level instead of looking to modern ideas of architects for comparison.





More Posts

Our Sponsors

Free Tech Publications