How fast could a 1000 piece jigsaw puzzle be completed

Suppose you take 12 hours to complete a 1000 piece jigsaw puzzle. If you had a friend helping how long would it have taken? it would probably not be less than 6 hours, unless you had some complimentary skills (e.g. he was good at recognising subtle shades of blue found in the sky peices whereas you could match a peice in your hand to the image on the box). For the sake of this discussion we'll say 6 hours.

What if we add another friend? We might find this one is particularly good at the matching the fine detail of the foliage and we get our time down to 4 hours. In all three scenarios the number of completed pieces per person-hour (ppph) is the same (83). Eventually though, adding another friend will slow down the ppph rate. For example when we have five friends working on the puzzle this may take 3 hours at a ppph of 67.

Most IT 'managers' understand this analogy - they understand that adding developers to a project (in order to deliver it earlier) will also reduce overall productivity. Many also believe that adding those extra developers will always reduce the time taken to complete the project. Let's return to our puzzling friends...

Suppose we now have a party of 10 friends working on the puzzle. We would surely start to see instances where two people are looking for peices which each other is holding, more than one person will want to look at the picture on the box at the same time, it will be impossible for everyone to access the puzzle at the same time - people will start taking peices away fit them together and bring them back for 'integration' into the main puzzle. The time taken to complete the puzzle may go back up to say 3.5 hours at a ppph of 29. (In reality some of the friends will get tired of the elbow pushing and go off to play diplomacy in the other room leaving 3 or 4 to complete the puzzle in less time - but this is an analogy so it didn't happen that way)

So adding resources can in some cases reduce productivty AND increase the time taken to complete a project. You may argue that this is not a good analogy - software development is more complicated than completing a jigsaw puzzle. Let's introduce some specialisation...

We could add some processes and specialisation of roles. First we could assign a few people to be 'puzzlers' who do the actual fitting together of pieces - one could do sky, one could do foliage, one could do buildings, etc. Others could be collectors - finding peices that the puzzlers need. One could be responsible for integration - constantly collecting and fitting puzzlers' completed puzzlets into the main puzzle. Once could be responsible for troubleshooting puzzlers problems (the puzzle gun). One could be responsible for making sure the puzzlers have access to the picture on the box when required.

We may have:
5 puzzlers
2 collectors
1 integrator
1 puzzle troubleshooter
1 picture manager

With this arrangement we may be able to make some improvements on our completion time - say to 2.5 hours at a ppph of 40. By specialising roles and adding processes and procedures (and hours of practice) we may even be able to add more resources and complete the puzzle in 2 hours (at a reduced ppph).

There would still come a point however that adding an extra person would tend to lengthen the time taken rather than reduce it. What is even more true is that if, say, you had a target of 2 hours to complete the puzzle and after 1 hour and 45 minutes it was clear that you were not going to make it, getting a few more friends involved to help will not be of no use if they are unfamiliar with the puzzle itself (the software in development) or the roles, responsibilities, and processes used (the development methodology & standards). The likely effect is that the puzzle takes longer to complete.

What have we learned:

1. The most efficient (cost effective) way to develop software is for one (highly skilled) person to do all the work.
2. Adding more people to a project is useful for small teams
3. Adding more people to a large project requires specialisation of roles and well defined processes
4. At some point adding an additional resource (even at the start) will make the project longer
5. Toward the end of a project adding an additional resource will normally make the project longer (this is Brook's Law)

The following charts show (purely conjectural) figures for efficiency and duration of puzzle completion.

Projected ppph figures for different numbers of friends completing the 1000 piece puzzle (process improvements made when 10 friend's were involved)

Projected overall time taken for different numbers of friends completing the 1000 piece puzzle

User Management

At ACP we've implemented a user management service used by all our custom-built apps to assign permissions to users. This was one of our first agile developments and I thought I'd share the thought processes behind its design.

The problem
Applications have functions (e.g. 'create a new blog'). Applications have users (e.g. 'Me'). Not all users are created equal. Some can perform many functions, some only a few. Some functions are used by many users, some only a few. Clearly we need a way to manage who can do what - ideally this should be provided with the minimal effort to develop and maintain.


Observation 1: A single application to manage assignment of users to functions for all applications would be useful. The problem described above is a generic one unrelated to a specific application. Result: Decide we need a User Management Application (UMA)


Observation 2: Functions and users have a many-to-many relationship. We could build an application which takes a list of users (e.g. from AD) and a list of functions for each application and provides a tool to map the two lists. Plus a service interface which allows an application to request the functions available for a particular user. Result: This will be OK for small apps with few users / functions, but will be a nightmare for anything larger.

Observation 3: Many functions are grouped for particular users - e.g. a 'Super User' may have access to everything, a 'Warehouse Manager' may have access to functions relating to managing warehouses. Result: These sound like Roles - we could extend the tool to map users to roles and roles to functions.

Observation 4: Some users have the same functions but they shouldn't have the same access to the same data. E.g. we may have a Sydney warehouse and a Melbourne warehouse - with a warehouse manager in each one. Result: UMA needs to support application dimensions (warehouses in the example above) but could be any 'filter' on data - e.g. publications, sales groups, departments. We can map users to dimensions.

Obversation 5: Sometimes an application needs to know who can do something rather than what someone can do. E.g. the application wants to show a list of people who can approve a photograpy purchase. Result: Allow the service interface to query by function (returning a list of users) as well as by user.

Obversation 6: If UMA goes down (so to speak) so will all our apps. Result: Firstly, only retrieve permissions on starting a session (a short outage would be less of a problem). Secondly, allow applications to store and revert to the last known permission set for the user if UMA is otherwise engaged.

Observation 7: When a new employee starts, HelpDesk will be asked 'can you give them the same access as Jervis Bean?'. Result: UMA needs to support profiles. We can map a profile to roles and dimensions and users to profiles (though we can still add explicit mappings for the user). Oh and we'll change the name to Profile and User Management Application (PUMA) since it's easier to rip off a logo...

Observation 8: Some dimensions should have one and only one user associated with a particular function. For example, there should be only one person who is the editor of Ralph. Result: PUMA should manage the multiplicity of the dimension / function relationship.

Benefits of Staged Software Releases

I recently had a meeting with a manager trying to get approval for a small/medium sized project. The project team advocated developing and rolling the solution out in three separate phases. This manager’s response was ‘surely this will take longer and cost us more?’ I’m not sure how common this is, but we countered his argument by making the following points:

1. Deploying solutions (particularly web based solutions) nowadays can cost very little $$$ especially if you’re adopting continuous integration techniques - so any percieved deployment 'overhead' is almost negligible.
2. Most applications that our organisation has developed over the years either include functionality that is never or rarely used and (at the same time) do not include functionality that the users would love to have. My estimate is around 20% unwanted features and 40% missing features. Delivering often and early allows you to get feedback from users that can change the direction of the project in time to reduce both of these figures.
3. If the project does not return the expected value you can cancel it after the first release rather than waiting to find out that it’s a dud after deploying the complete system.
4. Releasing the project in stages allows the roll out of the application and subsequent training to be spread over a longer period and can run in parallel with development. This can actually result in faster delivery overall.
5. Bugs are fixed closer to the time when they are created. If each release needs to be bug-free a bug cannot last in the system for longer than a single release. It’s widely accepted that a bug found early is easier to fix.
6. Early releases mean we can deliver business value sooner and can start depreciating the costs of the software assets sooner – the bean counters seem to like this.
7. Even if the project overall takes longer (but we didn't think it would) the perception from users is that it’s arrived sooner – the users will be using the first release early on, which will increase their sense of ownership, which will feedback to future development work. The perception of most development work is that it’s slow and unresponsive, frequent releases can help change that. In fact users are probably more willing to wait for subsequent releases if they can see progress being made.
8. In addition, this particular project would change some business processes, we didn’t want to change these too fast for the business, nor were we sure that the proposed changes would be feasible – the staged release helped us to mitigate these risks.

Most of these arguments could be applied to any project, whether or not you're applying Agile development methodologies or some form of 'mini-waterfall' process.

Productivity

Let's just dive straight in. Firstly you may be wondering about the url 'ADIWS' - well I'll tell you. I recently attended the Gartner summit Application development, Integration, and Web Services (ADIWS) here in Sydney. The content and speakers seemed a little disappointing at the time, but I've since been mulling over the presentations and decided to get some thoughts down on paper (or what passes for paper these days), hence this blog with a dodgy URL.
There was a lot of talk about corporate IT dev budgets being reduced, but corporate expectations for IT delivery increasing - i.e. business is demanding improved productivity from its development resources. It started me thinking about all the ways to improve productivity, here's my list (I'll expand on it more later). They fall into two main categories: a) do things more efficiently, and b) increase reuse.

1. Get coders coding faster, or more generally 'get your workers working faster'. Work, hardware, and software environments all play their part here. To some extent this is the dev tool providers' 'promise' - e.g. MS have always tried to differentiate VS with productivity features (e.g. intellisense), but they've also realised that coders aren't their only market - VS2005 will provide 'license streams' for testers and architects. We're also seeing more and more developers with dual screen monitors...
2. Perform less rework (=write fewer bugs). TDD is gaining momentum, and seems like a good solution to the problem of buggy code. If the code passes the tests it has no bugs, so keep going until they pass. What could be simpler? Oh - there's the slight problem that the developer writes the tests to code against, so this needs to be adopted with care.
3. Create the right software. I've seen plenty of custom code written (some of it even exactly to spec) that has not met the requirements of the business. What's the cause? Poor analysis? Wrong methodology? No prototyping? Fickle users? No business plan? I have my own ideas - what are yours?
4. Automate where possible. There's a few candidates here - the obvious ones like code generation of data layer or O-R mapping code, the regular build process, any project-independent, repetitive task (e.g. capturing code metrics), and laborious, high risk, manual work, even if performed infrequently should be automated (e.g. production deployments)
5. Spend more time producing working code. The software is the end product of our efforts so lets spend more time producing it and less time on setting up machines, searching for printer paper, creating / reading useless documentation, trying to squeeze requirements out of a user over the phone, setting up test data, writing a blog. This relates to one of the principles of the Agile Manifesto: 'Working software over comprehensive documentation'
6. Have a corporate IT plan. I've seen plenty of projects deliver 'interim-ware'. The dev team was promised that it would be replaced in 6 months when the Peoplesoft roll-out went ahead, but four years later the interim-ware code is still there as undocumented and poorly maintained as ever - oh and with lots of extra functionality because the Peoplesoft implementation was cancelled... With a company wide plan, informed decisions can be made about how much effort to expend on disposable software, or ideally avoid this development work altogether.
7. Use the DRY* principle at a company level. I can't count the number of security / permission schemes, code, and screens I've seen created from scratch - even for the same company. I'm not saying I'm a fan of cut and paste coding - but even this is actually better than repeating work that's already been done. Of course there are better ways to avoid repetition.
8. Use consistent integration methods. On the occasions when systems are integrated, the developers of each system get together for the interface debate - normally a battle of wills regarding developers skills, preferences, division of work, etc, the final agreement often looks like no other interface the company has developed. Standards of system integration efforts are required at the corporate level. You never know, with proper planning you may be re-using some of the interfaces later.

Feel free to post any comments.

*DRY---Don't Repeat Yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system [or enterprise?]. From the Pragmatic Programmer.