I was at the AIC 2010 conference yesterday, which I enjoyed more than last year. The most interesting session was Ivar Jacobson. He discussed how immature our industry is, with its disjoint between software engineers and academic computer scientists. Something I have commented on before when discussing if our industry should be licensed.
He discussed how we need to build our industry upon commonly agreed kernel of simple best practice activities, not upon some currently fashionable process whether it be Waterfall, CMMI, Agile, Lean etc. We must identify what are the best practices from all process (and all processes have something to offer) and teach them to students at University as this kernel of activities, as well as teaching how to compose them into more complex practices and hence whole development processes. Thus providing new entries to our industry with the base of reusable techniques that the can use for their whole career, irrespective of fashion. The key idea being that any current process model can be build by composing these kernel of basic activity.
So if this sounds interesting, and it does to me, have a look at www.semat.org. The signatories aim to have results within the year, if they achieve this aims this could well be the first step to making Software Engineering on a par with other chartered engineering disciplines such as Structural or Mechanical Engineering, with there is a long term set of industry accepted best practices that people can be judged against.
As I am sure you remember a few months ago Microsoft bought Teamprise and their Java clients for TFS. Well the team has got out their first Microsoft branded release, details can be found on Martin Woodward’s and Brian Harry’s blogs. This beta provides the first support for TFS2010
This release is very timely as I will be talking on the Java integration via the Eclipse plug-in at QCON next week and at the Architect Insight Conference at the end of the month. This “Eaglestone” release means I can hopefully do my demos against TFS2010.
I was at the Architect Insight Conference yesterday, so the big question is do I better know the role of the architect in the development process – I have to say no. Don’t get me wrong the event was interesting, I especially enjoyed the interactive group discussion sessions, one of which I chaired if that is the right term. As I have said about other conference I tend to find I get more from the discussions with other delegates than the more tradition presentation sessions.
For me the role of the architect is very fluid. There are many different ways to run a project and a company. Some define a role for the architect, usually those with more formal structures, for others the role is actually an emergent virtual role that the team as a whole perform, usually as part of an agile planning process. There is no single silver bullet solution for all project types, recognising this is probably the big insight of the conference.
Give this why does it seem that people aspire to being an architect? what do the think the role entails that makes it appeal so much?
A very noticeable comment in our interactive session was that recent computer science graduate did not seem to have done much programming as part of their courses. They all seemed to be focused on the business/analysis aspects of the industry. Is this driving people to the perceived glamour/rock star role of architect? More than one delegate went as far as to say they were now looking at A Level students to fill junior developer roles. Graduates were either not interest or lacked the skills companies would expect after completing a degree course. It was easier to train up suitable 18 year olds. In our industry a keen enquiring mind is more important than a degree, something that seems to beaten out of many people at university.
This harks back to my formative years, I was a thin-sandwich course student mixing 6 months at university followed by 6 months in industry (which I hasten to add I would not recommend, better a couple of years study and then a year out in industry). Many people I worked with were not student/graduate engineers but HND students, in my opinion an educational route sadly underused with this current government target of 50% of people going to university. HND’s aimed to turn out good technicians, people who knew the job of making and testing the product, but without the grounding in theoretical theory a graduate would have. Very much a craftsmanship point of view where staff are trained up within team, not arriving from university as the finished article.
So the key takeaway for the conference for me? Software development is a people/communication process. It is key to get everyone involved in the all stages of the process. Whatever else an architect is, they should not a person in an ivory tower lobbing out huge specification tomes to the minions below.