As some of you will recall, I was one of the Chairs for the European Patterns conference in 2008 and 2009. One of my responsibilities for the 2009 conference was to produce the conference proceedings. Well I’ve done it!
2009 represents a change for EuroPLoP. Until now we have published our proceedings in a physical book, a large book I should mention. This cost the conference organisers money (because it sold almost no copies), the money pushed up fees, and the proceedings were almost completely inaccessible unless you actually went to the conference. While some authors (like myself) put their papers online not everybody did.
For 2009 this has all changed, we’ve gone electronic. Thanks to CEUR EuroPLoP 2009 proceedings are available for free to anyone who want them. You can download individual papers or everything as one 30Mb PDF file.
So roll up, roll up, get your EuroPLoP 2009 conference proceedings here!
Thursday, March 25, 2010
Sunday, March 21, 2010
Change models: Shook, Schein, Dreyfus and Constructivism
Continuing on from my opening comments in the last entry, “Why forecasts fail: simple ones are better ”...
The other article which was good in the latest MIT Sloan Management Review was John Shook’s piece on change. His change model complements my own ideas well.
Shook’s model is shown below. He sees change starting with specific practices, e.g. just-in-time inventory, and as teams improve their practices and deepen their understanding they move to more thinking for themselves.
I’ve written before about my Agile triangle (or maybe pyramid is a better term). In the last few months I’ve added another insight into this model. Team which start by just “doing Scrum” or “XP” and want to advance, improve their process and practices further, deepen their understanding and application, take the next step, call it what you will, well, they need to advance by moving down the triangle.
You might start doing XP but over time you want to look outside XP and see what else is out there in the Agile toolkit. Deeper still is going back to Lean and picking up the Lean tools (value stream mapping, A3s, focusing on flow, etc.) And deeper still is a learning organization, a team or unit that is continually learning and changing.
While this goes some way validating my ideas its not the end of the story. Shook goes further and suggests his model parallels Edgar Schein’s writing - Schein is an MIT Management professor who has written extensively on culture and organisations.
Schein argues that organisational culture cannot be changed directly, indeed, to start with a desire culture in mind is a mistake. Better to start with the issues in hand and set about changing the cultural artefacts. Shook gives the model below (similar but inverted to the one on Wikipedia.)
It hadn’t dawned on me before, although heaven knows I once read plenty of Schein, that this isn’t far from my model. XP and Scrum, and other Agile methods, really start by changing the culture artefacts of an organisation.
Out go Gantt charts, in come burn-down charts.
Out go status meetings, in come stand-up meetings.
Out go moving deadlines, in come fixed iterations.
And so on.
Only later, are teams expected to reflect and modify their models - moving down the triangle/pyramid, moving from XP to Agile, to Lean, to a Learning Organization.
This also fits well with the Dreyfus model of skill acquisition which is so well liked by many in the Agile community. In this model a Master teach the pupils, when the pupils have mastered the skills they are allowed to think for themselves.
I’ve always disliked the Dreyfus model, and I believe it has failure built in. This is because the learner spends a long time looking to the teacher for the answers, they are not encouraged to find their own, indeed they are discouraged from trying anything different to accepted norm. Consequently someone may have mastered the skill they set out to, but they are no better at learning or problem solving. Faced with a new problem, or a need to deepen their understanding, and without a Master teach and ready made answer they are lost.
Maybe I over worry about this danger, as usual the truth is probably somewhere in between the two extremes. Rather than the Dreyfus model I look to the Constructivism model of learning. Under this understanding it is peoples understanding, derived from their experience which constitute learning. The teacher is not there to teach so much as to help individuals experience something different, the individuals sense making process then takes over.
Still, as I’ve said before: my interpretation Agile comes from Lean and the underlying idea of organisational learning. (Indeed, I think I wrote a book about that!)
As a result when I’m trying to make teams more Agile, I’m really trying to make them better learners, and make the organisation as a whole a better learner. While publicly we might be working down the Agile pyramid secretly I’m trying to work up.
The other article which was good in the latest MIT Sloan Management Review was John Shook’s piece on change. His change model complements my own ideas well.
Shook’s model is shown below. He sees change starting with specific practices, e.g. just-in-time inventory, and as teams improve their practices and deepen their understanding they move to more thinking for themselves.
I’ve written before about my Agile triangle (or maybe pyramid is a better term). In the last few months I’ve added another insight into this model. Team which start by just “doing Scrum” or “XP” and want to advance, improve their process and practices further, deepen their understanding and application, take the next step, call it what you will, well, they need to advance by moving down the triangle.
You might start doing XP but over time you want to look outside XP and see what else is out there in the Agile toolkit. Deeper still is going back to Lean and picking up the Lean tools (value stream mapping, A3s, focusing on flow, etc.) And deeper still is a learning organization, a team or unit that is continually learning and changing.
While this goes some way validating my ideas its not the end of the story. Shook goes further and suggests his model parallels Edgar Schein’s writing - Schein is an MIT Management professor who has written extensively on culture and organisations.
Schein argues that organisational culture cannot be changed directly, indeed, to start with a desire culture in mind is a mistake. Better to start with the issues in hand and set about changing the cultural artefacts. Shook gives the model below (similar but inverted to the one on Wikipedia.)
It hadn’t dawned on me before, although heaven knows I once read plenty of Schein, that this isn’t far from my model. XP and Scrum, and other Agile methods, really start by changing the culture artefacts of an organisation.
Out go Gantt charts, in come burn-down charts.
Out go status meetings, in come stand-up meetings.
Out go moving deadlines, in come fixed iterations.
And so on.
Only later, are teams expected to reflect and modify their models - moving down the triangle/pyramid, moving from XP to Agile, to Lean, to a Learning Organization.
This also fits well with the Dreyfus model of skill acquisition which is so well liked by many in the Agile community. In this model a Master teach the pupils, when the pupils have mastered the skills they are allowed to think for themselves.
I’ve always disliked the Dreyfus model, and I believe it has failure built in. This is because the learner spends a long time looking to the teacher for the answers, they are not encouraged to find their own, indeed they are discouraged from trying anything different to accepted norm. Consequently someone may have mastered the skill they set out to, but they are no better at learning or problem solving. Faced with a new problem, or a need to deepen their understanding, and without a Master teach and ready made answer they are lost.
Maybe I over worry about this danger, as usual the truth is probably somewhere in between the two extremes. Rather than the Dreyfus model I look to the Constructivism model of learning. Under this understanding it is peoples understanding, derived from their experience which constitute learning. The teacher is not there to teach so much as to help individuals experience something different, the individuals sense making process then takes over.
Still, as I’ve said before: my interpretation Agile comes from Lean and the underlying idea of organisational learning. (Indeed, I think I wrote a book about that!)
As a result when I’m trying to make teams more Agile, I’m really trying to make them better learners, and make the organisation as a whole a better learner. While publicly we might be working down the Agile pyramid secretly I’m trying to work up.
Monday, March 15, 2010
Why forecasts fail: simple ones are better
As regular readers may recall (one of my favourite expressions!)... I regularly ponder my subscription to the MIT Sloan Management Review. After a few dull issues - which leave me wondering if it is worth the money - it has once again come up with an issue with a couple of articles which justify the price for the whole year.
One of these is “Why Forecasts fail. What to do instead.”
The insights I find illuminating here are:
This fits in well with what I tell teams when I’m coaching and training in Agile methods. The simple estimation and velocity measures I advocate are better than the complex models which are too often preferred.
And it is no use asking a system expert (architect, senior developer, what-ever) how long it will take, their estimate is no better than anyone else. But, getting several different estimates (e.g. using planning poker or similar) is.
One technique suggested by the article is something I’ve tried in “future-spectives.” You say to the team, or individual, “Imagine we are at the end of the project, we have finished on time, in budget, everyone is very happy, what did we do right?” and the opposite: “Another failed project, what did we do wrong?” Imagining yourself in that situation can produce useful insights.
One of these is “Why Forecasts fail. What to do instead.”
The insights I find illuminating here are:
- Sophisticated, complex, models are good at fitting past data (“forecasting wit hindsight”) but they only not very accurate in predicting what will happen in the future (they tend to extrapolate)
- Simple models are not so good at explaining past data but are better at forecasting the future
- Human judgement is worse than statistical models at predicting the future
- Experts don’t predict any better than the average person
- Averaging the predictions of several independent individuals is more accurate
This fits in well with what I tell teams when I’m coaching and training in Agile methods. The simple estimation and velocity measures I advocate are better than the complex models which are too often preferred.
And it is no use asking a system expert (architect, senior developer, what-ever) how long it will take, their estimate is no better than anyone else. But, getting several different estimates (e.g. using planning poker or similar) is.
One technique suggested by the article is something I’ve tried in “future-spectives.” You say to the team, or individual, “Imagine we are at the end of the project, we have finished on time, in budget, everyone is very happy, what did we do right?” and the opposite: “Another failed project, what did we do wrong?” Imagining yourself in that situation can produce useful insights.
Sunday, March 07, 2010
The Scrum Hegemony & the Kanban Insurrection
One of the ideas I talked about in my Jax London presentation is something I call the Scrum hegemony and it deserves a few notes.
In the early days of Agile there was a tendency to equate Agile with XP, that changed a few years ago and Agile become (almost) synonymous with Scrum. I’m not saying Agile was XP or Agile is Scrum, just that to the uninitiated it can seem that way. (I blogged about this nearly 2 years ago now, see “Scrum is the new XP”.)
In many ways the Scrum people did a fantastic job of making Agile acceptable to the corporation. They had data and Harvard Business Review articles to cite, they didn’t ask the corporation to get into technical details (like TDD) and they had a friendly (English) name which avoided the word EXTREME! And most of all they had Certifications. O, don’t forget a pretty good marketing machine.
All this had the effect of making Agile acceptable to suited corporate types who didn’t know the first thing about software development but knew projects were always late. Ironically Scrum isn’t much more than XP, indeed, it is less than XP.
Consider XP: you can basically divide it in two. The bits about engineering (continuos integration, test driven development, refactoring, etc.) and the bits about managing the work (iterations, stand-ups, stories, etc.). Scrum, as documented concerns itself with the management side.
Granted Scrum expands on roles, Scrum adds some concepts like self-organising teams, adds some terms like backlogs and renames others (iterations to sprints) and adds burn-down charts but the management side of XP is basically Scrum, and Scrum is XP.
Purists might like to argue about which stole from which but the point remains: they are the same.
Scrum is devoid of the engineering practices, but as I’ve noted before in this blog: Scrum without the engineering practices is heading for trouble.
XP’s success, and the even bigger success of Scrum had the unfortunate side effect killing off most of the other Agile methods: FDD, ASD, Crystal, etc. Pockets still exists (especially with DSDM) but that is all they are, pockets. That was good for understanding but bad for experimentation and learning.
That’s now changing. The Scrum hegemony is now ending. Kanban, and perhaps other methods, are now offering alternatives. David Anderson’s Kanban insurrection is again offering an alternative. Kanban is again allowing the experimentation and variation in process that the Scrum hegemony has been stifling.
Don’t get me wrong, I don’t think for one moment Scrum is going to roll over and disappear, or that Kanban will dominate. Scrum will continue to be the Agile method of choice for corporations, it will be the 800 pound gorilla to use a phrase. But it will no longer be the only show in town.
Kanban is on the rise and drawing more attention to Lean, Software Craftmanship is on the rise and Tom Gilb’s work is being re-examined. There has long been a divide in Scrum between those who believe in “one and only one Scrum” and those who see “Scrum A, B and C” (I was going to post a link here to Jeff Sutherland’s blog but it appears he’s removed the post). Now there is a schism in Scrum: there are two bodies awarding Scrum certification, Scrum Alliance who’ve been around for a while and a Scrum.org backed by Microsoft and Ken Schwaber.
One of the good things about Scrum was that it was clear about what it was and was not - unlike Agile. This increasingly looks in doubt. As Scrum has grown more popular variations have set in, differences in certification and types of Scrum only add to those differences. The danger for Scrum is that it goes the way of the word Agile and becomes all things to all men.
That risk is echoed in the wider Agile family now. I welcome the rise of Kanban, not just because I think its a good system but because I think it is offering opportunities to think again about how we do things. But the end of the Scrum hegemony could leave the Agile as a whole fractured and incoherent, and decidedly not the type of thing corporations should be involved with.
Worst of all, it could see a new methodology war. There would be no winners here, only looses. Scrum and Kanban, and all the other methods, shouldn’t be rivals just alternatives. Unfortunately between the method zealots and in the commercial market I fear that message will be lost.
In the early days of Agile there was a tendency to equate Agile with XP, that changed a few years ago and Agile become (almost) synonymous with Scrum. I’m not saying Agile was XP or Agile is Scrum, just that to the uninitiated it can seem that way. (I blogged about this nearly 2 years ago now, see “Scrum is the new XP”.)
In many ways the Scrum people did a fantastic job of making Agile acceptable to the corporation. They had data and Harvard Business Review articles to cite, they didn’t ask the corporation to get into technical details (like TDD) and they had a friendly (English) name which avoided the word EXTREME! And most of all they had Certifications. O, don’t forget a pretty good marketing machine.
All this had the effect of making Agile acceptable to suited corporate types who didn’t know the first thing about software development but knew projects were always late. Ironically Scrum isn’t much more than XP, indeed, it is less than XP.
Consider XP: you can basically divide it in two. The bits about engineering (continuos integration, test driven development, refactoring, etc.) and the bits about managing the work (iterations, stand-ups, stories, etc.). Scrum, as documented concerns itself with the management side.
Granted Scrum expands on roles, Scrum adds some concepts like self-organising teams, adds some terms like backlogs and renames others (iterations to sprints) and adds burn-down charts but the management side of XP is basically Scrum, and Scrum is XP.
Purists might like to argue about which stole from which but the point remains: they are the same.
Scrum is devoid of the engineering practices, but as I’ve noted before in this blog: Scrum without the engineering practices is heading for trouble.
XP’s success, and the even bigger success of Scrum had the unfortunate side effect killing off most of the other Agile methods: FDD, ASD, Crystal, etc. Pockets still exists (especially with DSDM) but that is all they are, pockets. That was good for understanding but bad for experimentation and learning.
That’s now changing. The Scrum hegemony is now ending. Kanban, and perhaps other methods, are now offering alternatives. David Anderson’s Kanban insurrection is again offering an alternative. Kanban is again allowing the experimentation and variation in process that the Scrum hegemony has been stifling.
Don’t get me wrong, I don’t think for one moment Scrum is going to roll over and disappear, or that Kanban will dominate. Scrum will continue to be the Agile method of choice for corporations, it will be the 800 pound gorilla to use a phrase. But it will no longer be the only show in town.
Kanban is on the rise and drawing more attention to Lean, Software Craftmanship is on the rise and Tom Gilb’s work is being re-examined. There has long been a divide in Scrum between those who believe in “one and only one Scrum” and those who see “Scrum A, B and C” (I was going to post a link here to Jeff Sutherland’s blog but it appears he’s removed the post). Now there is a schism in Scrum: there are two bodies awarding Scrum certification, Scrum Alliance who’ve been around for a while and a Scrum.org backed by Microsoft and Ken Schwaber.
One of the good things about Scrum was that it was clear about what it was and was not - unlike Agile. This increasingly looks in doubt. As Scrum has grown more popular variations have set in, differences in certification and types of Scrum only add to those differences. The danger for Scrum is that it goes the way of the word Agile and becomes all things to all men.
That risk is echoed in the wider Agile family now. I welcome the rise of Kanban, not just because I think its a good system but because I think it is offering opportunities to think again about how we do things. But the end of the Scrum hegemony could leave the Agile as a whole fractured and incoherent, and decidedly not the type of thing corporations should be involved with.
Worst of all, it could see a new methodology war. There would be no winners here, only looses. Scrum and Kanban, and all the other methods, shouldn’t be rivals just alternatives. Unfortunately between the method zealots and in the commercial market I fear that message will be lost.
Tuesday, March 02, 2010
Jax slides
The slides from my Future of Agile presentation to this weeks Jax conference in London are now online. Although this talk started as a revision of last year’s Future of Agile (at ACCU and BCS Bristol) it ended up as a rewrite. The essential message is largely the same (key message: The future is lean) it brings out some new themes (e.g. software craftsmanship).
Later this month I’m presenting longer version of this talk to the BCS PROMS-G group in London as part of their Agile spring school, itself a repeat of the Bristol BCS Spring School last year. The longer version will include more on how to go about changing from where you are today to where you want to be.
Later this month I’m presenting longer version of this talk to the BCS PROMS-G group in London as part of their Agile spring school, itself a repeat of the Bristol BCS Spring School last year. The longer version will include more on how to go about changing from where you are today to where you want to be.
Monday, March 01, 2010
Last words on architects
Time to bring this mini series to an end. I’ve talked about
As a quick rule of thumb consider:
As a quick rule of thumb consider:
- The Product Owner (Produce Manager/BA): is concerned with the What
- The Project Manager: is concerned with the When
- The (your type of) Architect: is concerned with the How
- When you have a software system to design or fix, look to an architecture team not an individual. The team can share the vision in creating and exploitation.
- Never, ever, give someone the title Architect: give them the role yes, but never the title. Once you give them the title it is difficult to remove. And since you don’t know how their ego will respond you risk creating an problem. Architect is a role, not a title. Give people architect responsibilities but make sure they are still defined as a Software Engineer or whatever term you use were you work.
- The moment an “Architect” asks for an expensive tool to draw UML in then its time to let them go. UML can have a role but it isn’t worth spending money on. Expensive tools allow people to hide, architects shouldn’t hide. A cheap tool might be acceptable but don’t let them hide behind it.
Sunday, February 28, 2010
Segmenting Architects
Continuing my examination of the architect role I think we need to point out there is not one architect role my several. There is no such thing as an “Architect”, only an “Architect of something.”
Rather than talk about an “Architect” with one word we really should use two words. The first word describes what they are an Architect of, and the second, well thats the word “Architect”.
Some examples should help:
An Enterprise Architect: One who is concerned with the systems of the enterprise as a whole and how those systems fit together. By definition this architecture in the big and it means making architects at the grand level and not being concerned about details.
So: the Architect might rule that all new systems should be in Java, and not C# but they should not concern themselves with Java coding standards or which design patterns the Java developers are using.
A Solution Architect: these architects get involved in the early discussion about what the solution will look like. They may be responsible for sketching it, they may devise a prototype, they may be involved in customer conversations around requirements because you don’t know what you want until you see the solution; and this means they have some business acumen.
You might say these are the guys who have the initial vision for the final product. Importantly though: they need to stay with the development from start to finish. They can’t walk away once they have sketched out the initial vision. They can hand over to someone else with time but they need to keep skin in the game to have legitimacy and so they learn how effective their solutions were.
Ideally, when you start working on a product/project you want one of these guys involved but you want them to change hats as the work increases and become: a software architect.
A Software Architect: This is were my interest really lies, these are the guys who are custodian of the design vision for a piece of software, or application if you prefer. They are responsible for ensuring the whole team shares the same idea of how the software is designed. As such they are more responsible than most for how the software looks (inside) now and in the future but they are not solely responsible. Software Architects should have more experience than other team members but their responsibility is to lead through teaching.
Software Architects must implement, they need code under their finger nails if they are to retain their knowledge and legitimacy.
Their work includes:
I’ve avoided mention of roles like Network Architect, these might well exist but not always. Maybe you can think of some more architects in your organization.
I’m also avoiding the term System Architect because you have to define what you mean by “system” - where does it start and where does it end? Potentially System Architect is “Architect of Everything”.
These roles will also vary by organisation size. In a large organisation you might find these roles exist as distinct roles, in small organisations they are likely to overlap. So an Enterprise Architect also needs to do some Network Architect.
This is understandable but problems come when one individual is so busy wearing many hats that they neglect some aspect of one of the roles. They try and do two or more roles and end up doing one (or all) badly. Consider an Enterprise Architect who combines his role with being a Software Architect at the same time. If the Enterprise aspect dominates they may neglect involvement with coding the application so they cannot speak with experience about the application. Or, the other way round: they are so busy being a Software Architect that they don’t keep up to date with emerging trends and neglect the Enterprise side.
Rather than talk about an “Architect” with one word we really should use two words. The first word describes what they are an Architect of, and the second, well thats the word “Architect”.
Some examples should help:
An Enterprise Architect: One who is concerned with the systems of the enterprise as a whole and how those systems fit together. By definition this architecture in the big and it means making architects at the grand level and not being concerned about details.
So: the Architect might rule that all new systems should be in Java, and not C# but they should not concern themselves with Java coding standards or which design patterns the Java developers are using.
A Solution Architect: these architects get involved in the early discussion about what the solution will look like. They may be responsible for sketching it, they may devise a prototype, they may be involved in customer conversations around requirements because you don’t know what you want until you see the solution; and this means they have some business acumen.
You might say these are the guys who have the initial vision for the final product. Importantly though: they need to stay with the development from start to finish. They can’t walk away once they have sketched out the initial vision. They can hand over to someone else with time but they need to keep skin in the game to have legitimacy and so they learn how effective their solutions were.
Ideally, when you start working on a product/project you want one of these guys involved but you want them to change hats as the work increases and become: a software architect.
A Software Architect: This is were my interest really lies, these are the guys who are custodian of the design vision for a piece of software, or application if you prefer. They are responsible for ensuring the whole team shares the same idea of how the software is designed. As such they are more responsible than most for how the software looks (inside) now and in the future but they are not solely responsible. Software Architects should have more experience than other team members but their responsibility is to lead through teaching.
Software Architects must implement, they need code under their finger nails if they are to retain their knowledge and legitimacy.
Their work includes:
- Being a Senior Developer, hands on, they should have code under their finger nails
- Educating junior developers, sharing their knowledge, mentoring, teaching and training
- Guiding development towards a consistent and sustainable architecture
- Holding responsible for the shared technical vision and ensure it is shared
- Dealing with Conway’s Law: interfacing with non-technical manager types to ensure the technical and organisational architecture are compatible
I’ve avoided mention of roles like Network Architect, these might well exist but not always. Maybe you can think of some more architects in your organization.
I’m also avoiding the term System Architect because you have to define what you mean by “system” - where does it start and where does it end? Potentially System Architect is “Architect of Everything”.
These roles will also vary by organisation size. In a large organisation you might find these roles exist as distinct roles, in small organisations they are likely to overlap. So an Enterprise Architect also needs to do some Network Architect.
This is understandable but problems come when one individual is so busy wearing many hats that they neglect some aspect of one of the roles. They try and do two or more roles and end up doing one (or all) badly. Consider an Enterprise Architect who combines his role with being a Software Architect at the same time. If the Enterprise aspect dominates they may neglect involvement with coding the application so they cannot speak with experience about the application. Or, the other way round: they are so busy being a Software Architect that they don’t keep up to date with emerging trends and neglect the Enterprise side.
Thursday, February 18, 2010
Architects who aren't
Having cleared up some preliminaries, i.e. What is architecture?, we are getting closer to the big question: what do architects do? But I’ll continuing to take this piecemeal. In this blog entry I’d like to dismiss too groups of people who carry the Architect title but are not Architects.
The first group are “Architects by Seniority.” Some years ago I held a post with the title “Senior Software Engineer.” At first I though this might mean I was “the senior software engineer” but quickly realised I was one of many “senior software engineers.” The company conferred this title on anyone who had more than a few, about five, years of experience working as a software engineer. Or as I used to joke “anyone over 30.”
Some Architects get their titles the same way. My guess is this is more common on the services side of the industry were engineers are sold by the hour to clients and Architects have a higher billing rate.
A few months ago I was told it was common in the Indian outsourcing industry to confer the title Architect on engineers with 3 years experience. This is one data point, I don’t know how common that really is. Anyone out their know?
Unfortunately, some of the people who are given the title Architect simply because they have been around a while let it go to their heads. Which brings us to the second group who are Architects in title but not in practice: “Divorced Architects” or, as I think Joel Spolsky christened them “Astronaut Architects.”
These are Architects who sit around thinking big thoughts about “the system” but aren’t connected with what is actually happening. Just because you have the title “Architect” does not give you the knowledge or right to tell people what to do without doing it yourself. As Jim Coplien and Neil Harrison put it “Architect also Implements.”
If you are lucky these architects are pretty much harmless, they cost the company money, the developers tip their flat-cap to them in the morning but ignore them when they do work. If your unlucky their crazy ideas result in a messed up system and their egos get in the way.
Years ago I worked on rail privatisation, the Railtrack A-Plan timetabling system to be exact. It was on Windows NT with Sybase (yes, thats how long ago it was) in C and C++ with a little Visual Basic. 120 people worked on the system at the peak, of which four were architects and about 12 were coders, OK, maybe 16 if you include the SQL and VB guys.
But the architects came from a mainframe Cobol background so they designed a batch processing system, set down constraints and ways of working which just didn’t make sense for a client-server system. The company had a ISO-9000 system in place with lots of management so the result of this architecture was a lots of problems. Once they got into the code the developer just did what they wanted, the architects would never know because a) they wouldn’t get their hands dirty with code and b) they didn’t really know C let alone C++.
The project wound down and went into maintenance mode so I left. A couple of years later I found myself back on a much reduced project to redevelop parts of the system. Now we had about five developers, one architect part-time and a couple of dozen people tops.
We mostly ignored the architect, he saw one system and we saw another. ISO-9000 was nominally in place but widely ignored. The process worked a lot better. Occasionally we wrote a formal document to keep the formal process and architect happy but the real documentation was contained in “Rough Guides” which didn’t formally exist.
Moral of the story: Just because you are called an architect, just because you go to meetings, you aren’t an architect.
The first group are “Architects by Seniority.” Some years ago I held a post with the title “Senior Software Engineer.” At first I though this might mean I was “the senior software engineer” but quickly realised I was one of many “senior software engineers.” The company conferred this title on anyone who had more than a few, about five, years of experience working as a software engineer. Or as I used to joke “anyone over 30.”
Some Architects get their titles the same way. My guess is this is more common on the services side of the industry were engineers are sold by the hour to clients and Architects have a higher billing rate.
A few months ago I was told it was common in the Indian outsourcing industry to confer the title Architect on engineers with 3 years experience. This is one data point, I don’t know how common that really is. Anyone out their know?
Unfortunately, some of the people who are given the title Architect simply because they have been around a while let it go to their heads. Which brings us to the second group who are Architects in title but not in practice: “Divorced Architects” or, as I think Joel Spolsky christened them “Astronaut Architects.”
These are Architects who sit around thinking big thoughts about “the system” but aren’t connected with what is actually happening. Just because you have the title “Architect” does not give you the knowledge or right to tell people what to do without doing it yourself. As Jim Coplien and Neil Harrison put it “Architect also Implements.”
If you are lucky these architects are pretty much harmless, they cost the company money, the developers tip their flat-cap to them in the morning but ignore them when they do work. If your unlucky their crazy ideas result in a messed up system and their egos get in the way.
Years ago I worked on rail privatisation, the Railtrack A-Plan timetabling system to be exact. It was on Windows NT with Sybase (yes, thats how long ago it was) in C and C++ with a little Visual Basic. 120 people worked on the system at the peak, of which four were architects and about 12 were coders, OK, maybe 16 if you include the SQL and VB guys.
But the architects came from a mainframe Cobol background so they designed a batch processing system, set down constraints and ways of working which just didn’t make sense for a client-server system. The company had a ISO-9000 system in place with lots of management so the result of this architecture was a lots of problems. Once they got into the code the developer just did what they wanted, the architects would never know because a) they wouldn’t get their hands dirty with code and b) they didn’t really know C let alone C++.
The project wound down and went into maintenance mode so I left. A couple of years later I found myself back on a much reduced project to redevelop parts of the system. Now we had about five developers, one architect part-time and a couple of dozen people tops.
We mostly ignored the architect, he saw one system and we saw another. ISO-9000 was nominally in place but widely ignored. The process worked a lot better. Occasionally we wrote a formal document to keep the formal process and architect happy but the real documentation was contained in “Rough Guides” which didn’t formally exist.
Moral of the story: Just because you are called an architect, just because you go to meetings, you aren’t an architect.
Monday, February 15, 2010
Published: 97 Things every programmer should know
Kevlin Henney’s “97 Things every programmer should know” (the website) project has now advanced from website to book. Yes, you can buy a physical copy of “97 Things every programmer should know” (the book) from all good, erh, online bookshops - I’m guessing it won’t be in your local Borders or Waterstones.
As I’ve mentioned before two of the 97 “things” are mine. Of which my favourite is “two wrongs make a right.”
What is scary is that I know many of the contributors - I mean, well enough to have drunk beer with at least of dozen of the, perhaps 30, contributors.
Many years ago I overheard a wise old programmer telling some recent graduates: “There are only 3,000 good programmers in the world... and they know each other.” OK, I can’t remember if it was 1,000, 2000, 5,000 or 8,000, I do remember it was thousands, not hundreds and not tens of thousands. I’ve no idea how accurate he was, but I’m more and more convinced of the second bit. The best guys do know each other.
And what 97 Things shows is: Kevlin knows more of them than I do which means he’s probably a better programmer than me.
As I’ve mentioned before two of the 97 “things” are mine. Of which my favourite is “two wrongs make a right.”
What is scary is that I know many of the contributors - I mean, well enough to have drunk beer with at least of dozen of the, perhaps 30, contributors.
Many years ago I overheard a wise old programmer telling some recent graduates: “There are only 3,000 good programmers in the world... and they know each other.” OK, I can’t remember if it was 1,000, 2000, 5,000 or 8,000, I do remember it was thousands, not hundreds and not tens of thousands. I’ve no idea how accurate he was, but I’m more and more convinced of the second bit. The best guys do know each other.
And what 97 Things shows is: Kevlin knows more of them than I do which means he’s probably a better programmer than me.
Wednesday, February 10, 2010
Architecture or Design?
I mentioned the A word in my last post (Are there any System Analysts out there?). As regular readers might have noticed, I have over the years of this blog taken the odd pot-shot at Architects. But I’ve avoided direct comment on architect and architecture. Somehow it feels the time has come to address this debate.
I should say before we go too far that when I talk about Architecture I’m thinking software architecture. And when I talk about Architects I’m thinking about the architecture of software. I’m not thinking of network architecture, or business architecture, of course these topics are connected with software architecture but we need to narrow the topic down a little.
Nor am I talking about system architecture and system architects. System architecture is a particularly confusing concept because we first have to define the size and scope of our system: a piece of software is a system, so too is the computer it runs on and so too is the combination of both. So lets agree to leave system architecture to one side too.
Before we can tackle to subject of Architects I think we need to get a better understanding of architecture. So I’ll defer architects to another day and think about the nature of architecture today.
If we look up architecture in the dictionary then we find its all about design. Architecture is design. The word “architecture” (like the word “design”) is both a noun and a verb. Architecture is something you do (we may create a proposed architecture) and it is something you have, you software has an architecture whether it was design or not.
As an experiment, whenever you hear someone talking of “software architecture” mentally substitute the words “software design”. I don’t think you’ll find any loss of meaning.
Both design and architecture are, certainly in software systems and frequently elsewhere, part a deliberate attempt to create a particular outcome, they are also part emergent. How much is deliberate and how much emergent varies. As a result, the architecture (design) we finish with is something different to that which was planned.
(As an aside, we’ll talk about another time, that diagram is based on one from one of my favourite books, The Rise and Fall of Strategic Planning. There are close parallels to the way we relate to, and go about creating software architecture and business strategy.)
So architecture is design. Is it anything else? Anything more?
Architecture is more than design because the word architecture implies something bigger. An architecture is more than a design. You architect buildings but you design tents. Some of this “architecture as grand design” is just that, aggrandisement. It an attempt to make design into something grander. Personally I think design is a worthy and grand thing itself, you don’t need to aggrandise it any more.
In a software context there is the question of inside and outside. The term “software design” is often used to describe the external properties of the software, how it looks, feels, perhaps the features it offers. While
architecture often refers to the inside: how the thing hangs together and work. So there are “user interaction designers” but I’ve never heard of a “user interaction architect”.
I have long argued that software design exists in every line of code. Writing code is designing software. Certainly this fits with the “architecture is the inside” line of thinking but it doesn’t fit with so well with “architecture as bigger”. Somehow, while I happily argue that the choice between a FOR-loop and a WHILE-loop is an act of design, it seems wrong to argue that this is an act of architecture. But, according to own logic, that is what I am arguing.
The architect Ludwig Mies van der Rohe is reported to have said: “God is in the detail”. He wasn’t the first to use this quote but it does summarise his approach to architecture. He was an architect who was concerned about details. There was no lower bound for his architecture. So on that basis, Yes, whether you use a FOR-loop or a WHILE-loop, a bunch of IF-statements or a CASE-statement, you are making architectural decisions.
Architecture is design, it scopes up to the very big but it also includes the small details, because you just don’t know when the small details are going to become important.
I should say before we go too far that when I talk about Architecture I’m thinking software architecture. And when I talk about Architects I’m thinking about the architecture of software. I’m not thinking of network architecture, or business architecture, of course these topics are connected with software architecture but we need to narrow the topic down a little.
Nor am I talking about system architecture and system architects. System architecture is a particularly confusing concept because we first have to define the size and scope of our system: a piece of software is a system, so too is the computer it runs on and so too is the combination of both. So lets agree to leave system architecture to one side too.
Before we can tackle to subject of Architects I think we need to get a better understanding of architecture. So I’ll defer architects to another day and think about the nature of architecture today.
If we look up architecture in the dictionary then we find its all about design. Architecture is design. The word “architecture” (like the word “design”) is both a noun and a verb. Architecture is something you do (we may create a proposed architecture) and it is something you have, you software has an architecture whether it was design or not.
As an experiment, whenever you hear someone talking of “software architecture” mentally substitute the words “software design”. I don’t think you’ll find any loss of meaning.
Both design and architecture are, certainly in software systems and frequently elsewhere, part a deliberate attempt to create a particular outcome, they are also part emergent. How much is deliberate and how much emergent varies. As a result, the architecture (design) we finish with is something different to that which was planned.
(As an aside, we’ll talk about another time, that diagram is based on one from one of my favourite books, The Rise and Fall of Strategic Planning. There are close parallels to the way we relate to, and go about creating software architecture and business strategy.)
So architecture is design. Is it anything else? Anything more?
Architecture is more than design because the word architecture implies something bigger. An architecture is more than a design. You architect buildings but you design tents. Some of this “architecture as grand design” is just that, aggrandisement. It an attempt to make design into something grander. Personally I think design is a worthy and grand thing itself, you don’t need to aggrandise it any more.
In a software context there is the question of inside and outside. The term “software design” is often used to describe the external properties of the software, how it looks, feels, perhaps the features it offers. While
architecture often refers to the inside: how the thing hangs together and work. So there are “user interaction designers” but I’ve never heard of a “user interaction architect”.
I have long argued that software design exists in every line of code. Writing code is designing software. Certainly this fits with the “architecture is the inside” line of thinking but it doesn’t fit with so well with “architecture as bigger”. Somehow, while I happily argue that the choice between a FOR-loop and a WHILE-loop is an act of design, it seems wrong to argue that this is an act of architecture. But, according to own logic, that is what I am arguing.
The architect Ludwig Mies van der Rohe is reported to have said: “God is in the detail”. He wasn’t the first to use this quote but it does summarise his approach to architecture. He was an architect who was concerned about details. There was no lower bound for his architecture. So on that basis, Yes, whether you use a FOR-loop or a WHILE-loop, a bunch of IF-statements or a CASE-statement, you are making architectural decisions.
Architecture is design, it scopes up to the very big but it also includes the small details, because you just don’t know when the small details are going to become important.
Subscribe to:
Posts (Atom)