I'm presenting the Connected Applications: Security Basics talk at TechEd San Diego (vote now in the TechEd survey if you're attending). As part of the run up to the event I'm going to blog about some wider security topics, starting with the human aspects of security.
 
Although it's attractive to think that cryptographic techniques can provide perfect security this can never be the case where systems involve humans. The Art of Deception: Controlling the Human Element of Security by Kevin Mitnick illustrates this well. It is a book about Social Engineering, the practice of getting people to do things they wouldn't ordinarily do). It shows how easy it can be to circumvent an organisation's security through manipulating people.
 
The key point of the book is that natural human instincts to be helpful, avoid confrontation and respect authority can be easily used by a Social Engineer to get around an organization's security. Using fictional scenarios the book demonstrates how a Social Engineer can work. Some of the techniques involve posing as a fellow employee or a new employee requesting help. These techniques are often combined with sounding authoritative and being under time pressure ("I'm the new personal assistant to the CIO. I need to get the figures for the last quarter to the CIO for a presentation tonight otherwise I'll lose this job, but I can't open the spreadsheet on the network - can you help?"). The book also shows how easy can be easy it can be to get innocuous information (operating manuals, managers names, department codes, employee numbers etc.) that can be used in later communications to sound trustworthy and reliable.
 
The book demonstrates how the telephone and fax are great Social Engineering tools because they limited built-in authentication. It's easy to appear as someone else over the phone. In a large company with many different offices or a call centre it's possible to talk to someone you don't know personally and few people would think to validate the person's real identity.
 
Education and training are required to avoid falling victim to these techniques. The difficult part is that the attackers can take advantage of basic human instincts while victims have the harder task of acting against these instincts. The book finishes with a sample security policy for an organisation and flow charts to illustrate how to handle requests for information. This is useful but demonstrates how concerns about security need to be balanced against the ease of doing business (e.g. never take a message for a colleague from someone you don't know personally). I believe the threat modeling and risk-based approach are more useful techniques in helping an organisation come up with a security policy that successfully balances their security risks with their business practices.

The book's story approach did become a little tiresome at times, but overall I was impressed to see how humans are often the weakest link in a security system. While some of the stories involved high-tech techniques, such as hacking into the telephone exchange, others were simple cases of using influencing techniques to manipulate people.

On Monday 5 April, our first wedding anniversary, Hannah Marie Mitchell, our first child, arrived into the world.  You can see more photos and read more about it all here.

My wife did a superb job delivering Hannah without any drugs and in a very short period of time.  I was able to get really involved in the birth, actually 'catching' Hannah as she came into the world as well as the usual umbilical cord business.  An amazing, if incredibly gory, experience.

After the birth my wife's blood pressure dropped to the point where she passed out and started to fit; probably the scariest moment of my life.  Thankfully the medical staff responded quickly, and after lying for a while with her legs higher than her head she fully recovered.  After I'd recovered from the shock, a few hours later, in a sleep-deprived state I was thinking 'wow, thank god they knew how to reboot my wife after a system crash'. 

James Robertson, a Product Manager for Cincom (a Smalltalk vendor) presented this session on blogging.  James has written his own blogging software and news aggregator (BottomFeeder) in Smalltalk.  He appeared to me to be the Robert Scoble of the Smalltalk blogsphere and did a great job of blogging the conference, which was helpful for me as I forgot my laptop power strip.

This was an incredibly frustrating session.   Instead of starting with audience-focussed questions like What is a blog? How do I read one? How can I create one? James started by talking about the XML structure of an RSS feed and the differences between versions before showing or mentioning a news aggregator or web-page view of a blog.  To me this was like explaining the concept of the world wide web by starting with HTML tags and character encoding. 

I think James had previously given this talk to a group of highly skilled developers, whereas at this session it was only me and Martin Fowler who had blogs or even used news aggregators out of the 20 or so people in the room.

Although James was generally critical of Microsoft ("Microsoft Technology is an oxymoron!") he spent a lot of time to talking about the positive things that Microsoft were doing with blogging.  He mentioned Scoble, Chris Brumme and had even found and enjoyed Roy Osherove's posts.  He mentioned that the Microsoft bloggers helped put a human face on the company, built good community relationships and produced outstanding technical content.

The part I enjoyed most was the reactions of several Sun employees in the group.  They were shocked that Microsoft would allow there developers to write whatever content they liked in their blogs.  "How can you be sure that the material is honest and not edited by corporate marekting?" they asked.  "You can find Microsoft employees questioning or criticising Microsoft products" I responded.   They were deeply sceptical and couldn't see how it could possibly work and seemed deeply sceptical. 

I did enjoy the session's focus on how RSS could be used for many different purposes other than simply blogs.  Martin mentioned how he used a hand-crafted RSS feed for his articles (which I hadn't discovered).

Joshua Block a senior staff engineer at Sun and author of Effective Java gave a great session on API design.  Joshua highlighted that good API can be great company assets because good APIs capture and retain customers.  The talk was particularly enjoyable because Joshua illustrated his points with reference to good and bad Java APIs.  You can read the full session write up by James Robertson.

I love the challenge of API design.  As Joshua mentioned, it's incredibly hard, and when working on large public projects like .NET or Java you only really get one shot at it.  Once it's out there it's extremely difficult to make changes to it.

This is where I think the Indigo team is on a great thing.  Steve Swartz describes his role as making sure that the Indigo programming model is easy to use.  Don Box mentions today that he sees his role as removing the need to have to absorb complex detail in order to create working programs.  This team knows how important it is to get the API correct.  As Don said in January "the APIs are the real lock in".

I was surprised that Joshua didn't say more about the need to test the APIs with a developer audience.  He did mention that when designing and interface for others to provide implementations for, it's worth using the 'rule of threes' and writing three implementations yourself before shipping the API to ensure that it's possible.  But he didn't really say anything about API usability testing, the use of personas or the need to get APIs out into the community for feedback.  These are all things that I believe Microsoft is doing incredibly well with Longhorn (I'm not really in a position to say regarding Java, but would be interested to know what goes on there).

This session was led by Steve Freeman and Keith Braithwaite and was focused on what has gone wrong on projects that have done XP.  See James Robertson's post for a blow-by-blow description of the session.  I enjoyed the opportunity to hear the experiences of others who had applied XP.  It also highlighted some of the issues I have with XP.

The difficulty of the Customer role in XP
As I've said before, I think one of the weakest aspects of XP is the way it abstracts away the complex and difficult problem of understanding and designing software for customers behind a simplistic notion of an 'onsite customer'.   The danger from my point of view is that XP projects may ignore the benefits that good business analysts and interaction designers can bring, in lieu of developers just working directly with a customer. 

Even with these reservations, I really do like the way XP focuses on the customer.  One of the problems bought up in the group discussion I was involved with was that often developers are forbidden from talking to customers.  I think developers should definitely have access to customers, or at least 'personas' if the real customers are difficult to get to, and that good projects will also employ other people who have experience dealing with customers (such as BA's, integration designers and even usability experts).

Other points raised included that proxy customers must know their place.  Knowing the problem domain does not mean that someone knows how the solution should work.

Another point was the importance of standing up to the customer and challenging them rather than taking everything they say as correct (they are not always right or always able to say what they want).

The danger of XP sounding like a religion
One of the points was that 'dissenters should be tolerated as long as possible but no longer'.  The point was that one 'professional skeptic' can bring everything to a halt.  Another comment in the session was the need to understand the 'rigour of the disciplines'.  While I understand these points, the language concerns me as it sounds too much like XP is a religion.  This problem was acknowledged later in the session when it was highlighted that it was important not to frighten the customer by being a 'religious fanatic'.

Although XP isn't XP without all of the practices, these still aren't enough
Even though there are a lot of points about XP isn't XP without all the processes, it was also mentioned that the core practices aren't enough on their own.  Mistakes are sometimes made on projects where people have 'read the XP books' but not talked to anyone experience (there were a lot of XP coaches in the session). 

Keith said that mentioned that things like version control are 'assumed' in the core practices but need to be done on professional projects.  Other practices included doing some small design up front but avoiding big design up front (BGUF).  UML diagrams were OK, provided they were just on a whiteboard and not written down.  Also the test/code/refactor cycle wasn't enough to guarantee success, you also required knowledge, skill and experience (to know when to stop for example).

One of the comments I heard at the conference was that a lot of the successful XP projects have very talented people working on them and that this was one of the reasons for success. Any project with successful people is likely to do well, irrespective of the process.  To me this doesn't mean XP isn't useful, just that it may not be a processes that can be applied to all teams.

This session was run by Alan Cameron Willis who works with the Visual Studio team out of Cambridge in the UK. Domain specific languages are meant to express requirements and solutions of a particular business domain. Alan is working on the tools like Whitehorse that are visual designers included in Visual Studio that help development teams design and build applications.

We worked in groups to come up with our own domain specific language that we could use. We were asked to imagine that we had created a Point of Sale system for a restaurant and wanted to sell that solution to different types of restaurants (burger bars, bistros, drive-thru's).  Could we come up with a language that could be used to help model, sell or create the software for these different settings?

Alan suggested a range of different communication from text, to different types of diagrams (e.g. UML), to animations. The key issue from my point of view was who the language needed to communicate with and for what purpose. Is the language for communicating requirements or is it to capture requirements and generate the code?

It's nice to see that Microsoft have highly academic involved in creating their software, and that guys like Alan are also turning this into useful tools such as Whitehorse that we can use as developers.

Alan has posted a summary of the domain specific languages discussion on the OT2004 wiki.

I'm attending OT2004 conference (Michael Platt is also here and has blogged day 1) and had my first chance to hear Martin Fowler talk.  He did a keynote on MVC Patterns and the role of an Architect in an XP Team.

What is the MVC?

• Model - maintains state
• View - observes state and projects it to the user
• Controller - poked by user events and sends them to the model, which does some domain interpretation

The key idea is to avoid having domain logic inside the UI.  MVC is hardly ever done in the classic way.  There are two ideas inside MVC, one which is popular and one that is unpopular.

Separate the model from the view and the controller
The popular concept is to separate the model from the view and the controller.  The advantage of this is that things are layered, decoupled and separated.  The domain doesn't know anything about the presentation.  This is a Good Habit.

Separate the view and the controller
The less popular concept is to separate the view and the controller.  The original idea was that you could swap our or change the controller.  So if you had a read0only screen you could swap out the controller to ignore user 'pokes'.  The problem is that user controls often combine the view and the control.  A widget can receive input and display the results.  This second concept is often misunderstood and is one of the reasons for tangled descriptions about MVC. 

How MVC was messed up
One reason was the idea of Interface, Entities and Controllers.  The idea is that an interface represented the UI, the Entities represented the domain objects and the Controller was an intermediary that glued the entities to the interface.  The problem with this approach is that the Entities ended up just being structs and all of the behaviour was in the controller which was essentially procedural coding.

A lot of languages are out there but there is a shortage of OO code.  Martin wrote about this in the anaemic domain model - the domain model is just a thin wrapper around data.

Some people have solved this with a service layer.  The idea is that some of the logic associated with talking with other systems that is not wanted in the domain model.  The question is how to mix them.  Martin's view was that it was OK to have a thin service layer, but the key was to avoid having nothing in the domain model.

MVC variations
Based on talking with TW and others, Martin believes that there are two variations to the MVC model.  These are the presentation model and the model view presenter.  The drivers of these variations is testing.  This is another situation where testability has some good effects.

All too often there are two tier architectures where everything is in the view.  Testing in this approach is about driving the application through the UI.  This is too hard to keep updating, the test are fragile and it never works in practice.

So these variations are responding to the need to test without having to rely on the user interface.  One approach is to keep the view so stupid that you don't have to test it.  Another is to put the logic somewhere else.

Presentation Model
One key problem with the MVC model is that the view couldn't be a simple projection of the domain model.  Often you need to alter the data for the user interface.  Sometimes this is trivial, sometimes it isn't.  It's also hard to mix UI widgets with these adaptations.  Also, there is a need to store state that is about the UI and not the model (e.g. is this control disabled, is the text visible?).  Where should you put this in the MVC model?  The change is to have a presenter that is responsible for adapting the domain model for presentation and holds the view state.  It's also responsible for the synchronization with the state of the widget.  In the Presentation Model approach you can ignore the view and test the presentation which works as long as the synchronisation between the presentation and view is so simple.

The MVP Model
The twist in this approach is that the controller can't respond to the user's pokes.  The user pokes the view and the view pokes the controller (named the presenter in this model).  The Presenter tells the widgets to updated and then updates the underlying model   In the MVP model you can use Mock Presenters and test the messages are coming in order.

How do we group as a profession?  How can we improve what we do?
Martin's view is that we should have reflectors who wander around project trying to push our knowledge and practices along.  A lot like Martin really.

Why does XP have no technical lead?
This is where Martin spoke about his observation of David Rice at ThoughWorks and the way he worked as an architect.  He believes there are two views based on how you view the relationship between programming and design.  See his article Who Needs an Architect for more information.

Architects as Controllers
One view is that architects are the ones who come up with what has to be done and the programmers simply implement it.

Architects as 'Guides'
Architects in Martin's view should be someone who is still involved with a project but should be wandering around the team seeing things, making sure that problems are addressed.  Architects should be reactive to problems, and teacher-like helping to mentor the students.

The key for Martin was the architects should stay close to development, lest they become part of a centralized architecture team responsible for process and policy and really haven't developed in a long time.

Relation between XP Architects and User Interaction Architects
Martin believes that web UIs are popular because they are simple to put together and cheap.  Martin's beef with people like Alan Cooper and Interaction Designers are that they don't factor in the cost of designs.  Good Uis are expensive.  Martin handles this in XP by making a simple UI a user story then telling the customer to create another story for a better UI.

What's the link between the MVC and Architect topics?
Reflection.  They key is that Architects must be able to reflect on experience, which is hard.  They should look for what it is being done, decided what is good and bad about it and then communicate that knowledge to a wider audience (sounds a lot like an author doesn't it?)

Martin is a reflector on other reflectors, a sort of meta-reflector.  He mentioned that reflecting on experience is key.  It's the difference between a 9 to 5 job and someone who wants to get the best out of what they do.  Martin left us with the message that 'I have fun, you should look for opportunities to do that too'.

I attended the UK launch of BizTalk 2004 today.  Nearly everyone else there was in suit and tie, highlighting that BizTalk is a business focused product.  I like BizTalk and the 2004 product is a great improvement on previous versions (Darrel Norton has a great list of BizTalk resources).  Messaging and integration are two areas where I think IT can add a lot of business value.  BizTalk is making technology that had previously been very expensive available to greater number of customers and developers.  As Cameron Reilly notes, one CIO he knows says he could buy BizTalk 'out of the stationery budget'.

There were some interesting customer presentations including how Virgin Megastore were using BizTalk to spot employee theft by analyzing real time point of sale information (case study here).  Loss Prevention Agents (I'm thinking Agent Smith from The Matrix) are notified on their mobile devices as business rules are triggered. 

My favourite customer moment was the CTO Scottish and Southern Energy who revealed their unofficial mission statement was "boring but successful".  Brilliant.

Mehran was there with his assortment of Microsoft OS gadgets and even gave me a ride back to London in his very nice new BMW with Windows Automotive.   This is serious geek gadgetry.  There's 'Toy Boys' like Carl Franklin sings about and there's guys like Mehran who go out and buy the car.

Don Box points out the Death of Hypercard.  I loved HyperCard.  I lost my 'programming virginity' to it when I used it to build a custom web browser and hyperlink editor as part of my Psychology Honours Thesis.  It will always have a special place in my heart as my 'first time'. 

Sure, I'd done some great work in primary school with the Logo turtle, and spent a long time learning Basic programming on the Commodore 64 (annoying my brothers who wanted to watch the TV) but I'd never 'released' anything for other people to use.  Here are some things I learnt (more about the thesis at the end).

What I learnt from my 'first time'
Here are some learning experiences that stuck in my mind:

• Estimating development time is difficult.  I was incredibly optimistic and ended up being late and having to cancel the first day of the experiment.
• Coding through the night is a waste of time.  In desperation I had stayed up programming through the night to get it finished.  After a sleep the next day I realised that everything I did post midnight was useless and had to delete it.
• Pair programming is a great way to learn.  After pulling the all-nighter my brain was fried but the program wasn't finished.  Luckily a friendly network admin in the psych department paired with me and helped me solve a complex problem.
• Milestones and frequent, iterative releases are a Good Thing.  I tried to do it all in one go and make it 'perfect' rather than focussing on getting it working end-to-end and gradually adding features.
• Usability testing is important.  Although I showed the program to friends, I didn't actually get anyone to use the software before I started the experiment.  Having to watch 200 people struggle with my poor interface was an important lesson in the importance of doing some discount usability before spending time writing code.  Ironically enough, one of the main authors I referenced in the thesis was Jacob Nielsen (in his academic phase, before the crazy days of the dot-com).
• Books are a great way to learn.  I love books as a way of learning something (I even taught myself to juggle from a book).  I used Danny Goodman's The Complete Hypercard Handbook (here's his view on the death of Hypercard) to teach myself how to implement my solution.  I got everything I needed from there (even implementing my own scrollbar with user-drawn arrow heads and mouse tracking).  Later I got his JavaScript Bible, which was the most expensive book I'd ever bough at AUS$70 but translated into a AUS$2000 contract to build a multiple choice system for the uni.  I couldn't believe the financial leverage!  Recently I've dampened my love of books slightly in favour of learning by 'just writing the code'.

What was my thesis about?
My thesis was looking at whether hyperlinks could be useful in helping people learn (the thesis is now available to the public at my uni library).  I built a set of pages describing key topics in first year psychology that the first year students could use to revise for their exam.  In my study there were three groups of students - those who browsed a set of hypertext pages (we'd say web pages today) which had links authored by the Lecturer, and two other groups that had to link the topics themselves.  One group had to choose from a list of associations to describe the connections between two topics and the other group had to type a description of a relationship themselves.  My hypothesis was that the groups that created the hyperlinks would do better at remembering the material (and get a better exam grade) than those who just passively read the material.  In the end there were no significant relationships (ever the way in honours topics), but it was a great excuse for me to learn how to program.

Another great night at the Extreme Tuesday Club where I met Chris Matts, a Business Analyst (or Agile Business Coach) who works for ThoughtWorks.  It was an interesting discussion about the role of an analyst in a XP/Agile project.  Chris views his role as helping the business customer and the development team get closer together and helping the developers learn more about the customers' domain problem.  This kind of thinking about software development practices is a key reason why I like the XP/Agile movements.

I'd heard about the great work Chris had done on a large project that was going off the rails.  By tracking close to the business issues he was able to influence the project being cancelled and restarted.  We spoke about how to influence projects when it's obvious they aren't going to be successful, the complexity that can be involved when the contract work depends on the project continuing and the personal integrity involved in sticking with a decision you believe in.

I was interested to find out more about how a Business Analyst fits into such an Agile-oriented work place.  To me one of the big gaps in the Extreme Programming methodology is the generic concept of 'The Customer'.  It's a great thing that a lightweight methodology exists that is pushing the importance of customer involvement, but to me XP is thin on the details of what's involved.  In XP Refactored the authors point out that the notion of the onsite customer is a difficult idea to achieve.  Most work places wont allow their best people to leave the workplace in order to sit alongside the development team.  Even if they did they aren't always able to effectively communicate with the team.

Chris' concept was that he understood the technology and the business domain knowledge.  He believed that one of his benefits was to bring the customer and the development team closer together.  He was more effective than just a customer because he was skilled in learning about the business problems and analysing the requirements for a solution. He believed he had a role to play in an Agile team by viewing his role as the Business Coach focussed on transferring his business knowledge through to the development team.

One of the techniques that Chris mentioned as being effective was having the customer draw the business model on a blank sheet of paper at each meeting.  They found this produced much better customer feedback than they received from the customer reviewing their diagrams.  Drawing and talking about the business model produced a greater involvement than someone simply reading and reviewing a document.

Chris had extended this idea further with the concept of producing documents as a way of learning more about the business himself, but not necessarily publishing or sharing those documents with the team.  A very 'Agile' perspective that says the value of the analysis is the impact it can have on the rest of the team.

Quite an interesting discussion developed around the concept of 'How People Learn' or how a Business Analyst could help the team learn about the business.  I take the 'constructivist' perspective which says people learn through constructing their own view of the world.  The key to learning is to engage people in thinking in order to develop more sophisticated connections between concepts.  Any activities that encourage people to actively think about topics and relationships between topics are good.   Drawing a diagram and talking about it are much more likely to engage someone in thinking than passively reading or reviewing a document.

Optimizing is a complex problem.  Deciding what to do about our coming baby's nappies (US translation: diapers) highlighted the need to understand what is being optimised and what the trade-offs are.

Currently my wife and I have been discussing what to do about nappies for our coming baby.  I'm still dealing with this at a numerical rather than the emotional level as I'm still dealing with the sock that there may be over 5000 nappies in the first few years of a child's life.  While disposable nappies have the attraction of convenience it just feels bad to throw that many things out.  There's lots of evidence that disposable nappies represent around 2% of landfill and are generally evil as this clearly biased site  demonstrates.

I spoke about this problem with a good friend of mine who studied Computer Science.  He was a father himself and didn't like the idea of not using disposables because of landfill.  He came back to me last week with the following comment:

"While it is true that nappies do contribute to a small amount of landfill, there are great contributors to landfill such as kitchen waste.  As a Computer Scientist if I was trying to optimise something I'd start with the area that I could have most impact"

I liked my friend's thinking and told it to my wife, who said "yes, but choosing a cloth nappy washing service is a simple decision that is easier to implement than having to think about all of our waste".

I'm not sure which approach is "right" (we'll be using a cloth service for the first month) but to me it highlights that optimization is a complex problem that involves understanding what to optimize and what the trade-offs are.