Software Project SOS
An exercise in crowdsourced consulting
I ran my "Software Project SOS" session at Skills Matter on Thursday evening and it was brilliant fun. The premise behind the session was to present the current state of a struggling software project and understand what could be done to fix it.
To set the scene, rather than describe the software project myself I asked everybody to imagine they were taking over a project that they had no exposure to. In order to understand what state the project was in, they had to ask me questions to explore the situation and discover the important information (an important consulting skill).
With the facts discovered (the white index cards in the photos below), I then asked everybody to vote on those they thought were the most important to do something about in order to bring the software project back on track.
The voting certainly picked out the big-ticket items that needed fixing in this particular scenario and it was amazing to see this unfolding. No helping, no prompting; everybody just jumped on these items.
For the final part of the session, I asked people to pair up, take a couple of the cards and jot down some ideas of the changes they could make to turn the project around.
The room was buzzing for about 5-10 minutes while everybody was throwing ideas around and busily writing up those ideas on post-it notes. The end-result is what you see above and the full set of photos showing all of the suggested changes is available to view online.
Take a look at the photos for yourself. They're mighty impressive when you consider that very few of these people had met before and they came from different backgrounds, with different levels of experience working on different types of software. Yet, as a group, they identified the key problems that were causing the project to struggle and came up with a number of ways in which they could be resolved.
The other thing that I really admired was the level of pragmatism exhibited. There's an awful lot of evangelism being thrown around the IT industry at the moment, particularly with the buzz around lean, agile and software craftsmanship. Clearly many of these ideas are appropriate for turning this software project around, but nobody was stood up chanting that "agile is the one true way to build software", for example. The scenario we used was based upon a combination of real software projects and included a fair share of real-world constraints that couldn't be overlooked. They had to be taken into account and this is why the results of the session are so impressive - everything suggested was relevant, applicable and pragmatic.
Thanks again to everybody that came along and made it such an excellent evening ... I'm certainly looking to run this again.
Software architecture training in London - Feb 2011
Skills Matter, 7th Feb 2011
The next public scheduled Software Architecture for Developers training course takes place at Skills Matter in London on the 7th/8th of February.
The course is aimed at software developers that want to understand more about pragmatic software architecture and particularly recommended for those that have recently moved or about to move into technical lead type roles. It's also for anybody that believes software craftsmanship is important. ;-) There's an updated preview of the content if you want to see the sort of stuff we'll be covering and some testimonials from people that have been on the course.
p.s. I'm also in London next week and I'll be presenting an "In the brain" session at Skills Matter called Software Project SOS. Feel free to get in touch if you want to meetup.
Software craftsmanship ... I want it all
And I want it now
I did a talk today for the local BCS about how to get started if you need to design a software solution when all you have is a business vision and a blank sheet of paper. During the Q&A towards the end of the session, somebody asked whether the 80-20 rule was still holding true. In this particular case, the question was about whether software was developed in 20% of the time, with the remaining 80% being needed to make it actually work. Reading between the lines, in my head, I translated this as "does software development still suffer from the same old quality problems?".
My response was that some software teams do work this way and I'll stick by that. I've seen teams essentially writing crap and then relying on excessively long testing phases or large post-development maintenance contracts to patch all of the holes that shouldn't really be there in the first place. Other teams, however, put emphasis into actually getting it right first time using a lot of the "good" practices that you'd associate with modern software development; automated testing, continuous integration, source code control, patterns, reuse, etc. I'd also suggest that such teams can probably get it right way quicker than those other teams churning out whatever it is they do churn out.
If you've been following the software development blogosphere recently, you'll have seen a ton of stuff about software craftsmanship. The question I was asked is a perfect example of how doing a good job differs from doing a bad job. Craftsmanship if you like.
Now, there have been lots of posts recently about what software craftsmanship is or isn't; including discussion about what characterises a craftsman, whether it's just about beautiful code, whether it's about delivering what's expected and so on. For me, it's simple. I want it all and I want it now ... software that exhibits good design, is of a high quality, has beautiful code, works, meets expectations and generally makes everybody engaged in the process happy. I also want it to be done efficiently, effectively and with minimum messing around.
Our industry is a bit of a mixed bag. Some developers are excellent, always striving to improve, while others are just in it for the money. However you look at it, this software craftsmanship stuff is mainly about improvement from within. I train developers on a regular basis and I'm trying to do my bit to help teams build better software. But what we really need is for people outside of the industry to start peeking in and see what's going on. I know it would be hard to achieve, but I do think that there should be some way for people using our services to differentiate the good from the bad. Many vendor-based certifications are essentially worthless and they certainly don't reflect anything about the craftsmanship aspects that people are talking about. A Microsoft certification might reflect that somebody knows what an ASP.NET page is, but could the holder of that certification actually design, build and deploy a robust, decent quality website that did what it was supposed to?
Many people engaging software development services have very low expectations of software teams, probably due to past failures or because they've hired 9-5 developers that were paid too much, didn't know what they're doing1 and delivered nothing2. Others are simply naive about the whole engagement process and are being taken for a ride by organisations taking advantage of this fact. As an industry, I think it's time for some differentiation and professionalism across the board.
1 Are half of IT professionals useless?
2 A friend told me a story about a contractor that was tasked with building a database-driven website and he basically only delivered a HTML mockup. He would always drive the keyboard during demos and nobody ever doubted his progress. But one day he was rumbled, left in a hurry and was never seen again. Beware the developer with no shoes.
Software project SOS
Skills Matter, 6:30pm, 27th January 2011
A short note to say that I'm running an "In the brain" session in London at Skills Matter on the 27th January. This session is going to be very discussion driven, where we'll try to figure out what to do if you need to get your software project back on track.
Software project SOS
If you believe what you read everywhere, all software teams are writing their applications using the latest technology with a comprehensive set of automated tests on their highly productive agile projects. Unfortunately the reality for some of us is far from this, with our projects suffering from a range of problems. In this session, we'll be looking at one or more software projects that are having issues and explore how to resolve them in an effective yet pragmatic way. Please get in touch by e-mailing simon.brown@codingthearchitecture.com if you want to see your own (anonymised) project featured in this session. This is your opportunity to get some free consultancy or to get a glimpse of how other software teams approach their projects.
The fun starts at 6:30pm and you can find more information on the Skills Matter website.
Planning the year ahead
Happy new year to everybody and thanks to all of you that I've worked with during the past year. 2011 is shaping up to be an exciting year and I just wanted to summarise some of the things that we have planned.
Software architecture introduces control
Only you can decide how much is right
A while back I wrote about how software architecture introduces structure and guidelines, consistency and clarity into software projects. When discussing this on the training course over the past few months, it's become clear to me that software architecture is also, in reality, about introducing control.
I interviewed a team leader today and when the conversation turned towards quality and specifically quality assurance, I was told that he was fortunate to work with a team that were very competent. It's a fair answer, but my follow-up was "how do you know that your team members are competent?".
For me, software architecture is about reducing the number of assumptions that are typically made on software projects, thereby reducing the number of ugly surprises that bite you further down the line. For most projects, benefits can probably be realised by introducing control and restraint, for example, to stop team members going off on tangents. Scrum does this through the introduction of sprint backlogs so that the team has focus on what they need to deliver during any given iteration. Likewise with software architecture; you need some degree of control in order to introduce structure and guidelines, consistency and clarity. For example, you can't have people writing database access code in your view components if you've designed an n-tier application in order to support some of your key non-functionals. Ditto things like ensuring that all of your components are stateless so that they can be scaled-out to cope with additional load. It's also about simply having a clear and consistent structure to your codebase; appropriately organising your code into packages, namespaces, components, layers, etc.
How much control do you need?
The real question that needs to be answered on any given software project is how much control needs to be introduced? At one end of the scale you have the dictatorial approach where nobody can make a decision for themselves versus the other end of the scale where nobody is getting any guidance whatsoever. I've seen both in real-world software projects and I've taken over projects where everybody on the team was basically left to their own devices. Introducing control on this sort of project is really really hard work but it needs to be done if the team are to have any chance of delivering a coherent piece of software that satisifies all of the original drivers.
So how much control do you introduce? My own answer is that it depends on a number of things...
- Are the team experienced?
- Have they worked together before?
- Are the project requirements complex?
- Are there major constraints that need to be taken into account?
- What sort of discussions are happening on a daily basis?
- etc
I've also noticed that different countries and cultures place different values on control. Some value control and the restraint that it brings whereas others value empowerment and motivation. There's no universally correct answer, but it is worth thinking about how much control is right for your own software project.
Slides from Software Architect 2010
Available to download/view online
If you follow me on Twitter you'll have seen that I recently presented a number of sessions at the Software Architect 2010 conference in London (I used the #sa2010 hashtag for my conference related tweets). There were four sessions in total; a couple of workshops and a couple of 90 minute sessions, all of which were focussed around software architecture and how to perform the role of a software architect well. If you couldn't be there but want to take a look at the content, here are some links...
- Software Architecture in a day (slides from the workshop)
- Where do you start? (slides from the presentation)
- Boxes and Lines (photos of the output from the workshop)
The links are on the Software Architect site too. Thanks to Nick, Chris and team for an excellent event, plus everybody that came along and made it so worthwhile... :-)
- nice session/workshop on Non-Functional requirements led by @simonbrown! trying to decide on which final day workshop to attend! ...
- @technige @simonbrown totally agree one of if not the best speakers at the conf ...
- @simonbrown thanks for your sessions over the past 2 days very insightful :-) ...
- highlight of #sa2010 today was @simonbrown on non functional requirements and Tobias Komischke on web 2.0 v human 1.0 ...
- highlight of the #SoftwareArchitect2010 conf today was @simonbrown on just enough architecture and @neal4d on emergent design ...
Speaking at the Software Architect 2010 conference
19th-22nd October 2010, America Square Conference Centre, London
Just a quick post to say that I'm speaking at the Software Architect 2010 conference in London next month. I'm running a pre-conference workshop, a post-conference workshop and two technical breakout sessions as follows.
Software Architecture in a Day (pre-conference workshop)
This one-day workshop is an interactive introduction to software architecture and what it means to be a software architect. It's aimed at software developers who are looking towards their first software architect role, developers who want to become more architecturally aware and software architects that are new to the role. We'll be asking and answering the following questions:
- What is software architecture?
- What is the role of a software architect?
- How do you define software architecture?
- How do you share software architecture?
- How do you deliver software architecture?
Where do you start?
One of the hardest things about software development is being asked to come up with a design when all you're given is a set of requirements and a blank sheet of paper. Many software teams will dive straight into the code and while this can initially be very productive, the slippery slope of constant refactoring is awaiting those teams that haven't quite found a design that works. Often, a little forethought is all that's needed to get the development process heading in the right direction. So where do you start?
How do you design for non-functional requirements?
You may have heard people talking about "non-functional requirements", mentioning things like performance, scalability, availability, security, flexibility and so on. What do you do if you're asked to design software that exhibits these qualities and furthermore, how do you do it in a pragmatic way? Come along to find out about some of the approaches that you can adopt and some of the trade-offs you'll need to make.
Boxes & Lines (post-conference workshop)
Talking about software architecture will get you so far, but in reality it's all about experience and that's exactly what this workshop offers. Given a set of functional requirements, you'll be asked to identify the other architectural drivers before doing some design, choosing some technologies and drawing some boxes and lines. Join us if you want to know where to start with designing software and how to go about the software architecture definition process in a lightweight, structured and pragmatic way.
Feel free to stop me and say hello if you're at the conference; should be a great event.
Maintainable Systems 2
More On Upgrades
A little while ago I wrote a piece about maintainable systems and upgrades. My own upgrade project has been progressing slowly and I'm going to write a few more thoughts.
A successful system might (hopefully) be around for many years. It's highly likely that such a system is going to need upgrading periodically. The user's requirements might change over time, different users might want to use the system, external interfaces may change and, of course, software salespeople will want a reason to charge upgrade fees (I'm such a cynic).
If you intend your system to be successful then your design should allow for upgrades. I'm currently involved in an upgrade project and it's painful. I also have to admit that when designing systems from scratch I've made many of the same mistakes and probably made the user's life difficult. So here are some of my recent problems that I should remember when I'm back on the other side.
It's not a clean install so there is going to be data. Can you migrate all the data in the system? This seems obvious but be careful with accuracy of numbers, text data in other languages and empty and null fields. Consider what could be there and not just what you think should be there. Don't be surprised if a free text field, where you were expecting a number, has the word “five” - or in my case 3M for 3,000,000.
How long will the upgrade take to perform - in particular per data item? Your users may have been running the system for years and have a lot of data. If they are using it in a way that differs from your expectations then they may have a large number of items where you expect a few. In particular make sure that there are no manual steps per data item e.g. having to edit something in a GUI. If it takes 5 minutes to do but I have 5000 items then it would take weeks.
Have you changed an implicit API? Common examples include log files and database schemas. I like to use a log monitoring tool to find exceptions but it is also common to trigger external processes from a log indicating a certain point has been reached. Your end users may have also written SQL scripts to interrogate your back-end database and produce reports. Don't blame your users/customers for doing this as it probably indicates a gap in your product!
Be careful when you 'improve' a GUI. It may be much better but the end users will now need to be re-trained. Like the data migration problem this can be a problem of scale. Telling a system administrator where to enter new user data is not hard but if it's the interface to a Point Of Sale terminal used by 20,000 shop assistants then the costs are high. Having said this I do believe that if you do make a change then you should stick to it – leaving old, deprecated screens as well as the new ones leads to a support and training nightmare. The current product I'm upgrading has four different GUI screens for one type of data element because different customers have either demanded a new screen or refused to stop using an old one. They all work differently and have different bugs in...
Does a change in software process imply a change in the business process? Your users/customers may have adapted the way they work around your software so any improvements you make could force other changes. This could meet with resistance.
Lastly, please consider the final stage of the upgrade process – testing! You've probably/hopefully performed enough tests so you're convinced it works in the way you expect but your customers may have different expectations. They will almost certainly want to perform their own tests. My current project includes a third party finance application. What I want to do is produce reports for the same point in time in the old and the new systems and compare the totals and individual line items between the reports. If I can't generate comparable reports then I'd have to do this comparison by checking the individual lines. If I do it manually I'll get a much lower level of coverage and the edge cases might be missed. If I can't do the comparisons at a fine grain level then I can't track down where any problems are occurring.
My summary is below but I'd love you to send me some additions.
- Minimise manual upgrade actions
- Talk to your users/customers
- How do they actually use the product?
- Can you get a copy of their data to do some test runs?
- The customer is always right. Any deviation from your expectations is free market research
- Make it easy for your users/customers to do their own testing
Good code isn't enough
Video, slides and photos from my talk at Skills Matter
I presented an "In the brain" talk at Skills Matter last week entitled "Good code isn't enough" that looked at whether "good code" guaranteed a successful software project. I had a great time and there was some really good discussion about the factors that can affect whether a software succeeds or fails. The whole session was recorded and the video is available to watch online. The slides are also available to view online and download.
For those interested, here are photos of both sides of the whiteboard from the session.
What is good code?
Is good code enough?
If you want to learn more about the topics that we covered in the session, take a look at Enterprise Software Developer; a four day practical training course about building software within an enterprise environment in a structured, lightweight and pragmatic way.
P.S. congratulations to Peter Howarth who won the raffle for a free place on his choice of Software Architecture for Developers or Enterprise Software Developer.
