tag:blogger.com,1999:blog-43277597408255729232024-02-06T19:50:37.045-08:00Getting over the finish line on software projectsIan Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-4327759740825572923.post-90519201272905624442009-09-16T23:32:00.000-07:002009-09-16T23:44:31.418-07:00Why Waterfall won’t die soon?<p><strong>Current development techniques are unrecognisable from the days of punch cards and tick-a-tapes and the constraints of yester-year. Over the decades the legacy of these primitive development environments lingers on, not in technological terms but in mentality terms. The Waterfall generation has now matured and they are now running and directing the projects using what they know best – which is why it won’t die soon.<br /></strong></p><br /><p>Many decades ago software development was a very time consuming and expensive undertaking. It was difficult. If you programmed a computer using punch cards then you needed to be very clear up front on your requirements. Debugging punch card systems was notoriously difficult and time consuming. Doing a dry run through your deck of punch cards could aid in reducing bugs but it couldn’t prevent badly defined requirements or misinterpretation of requirements. For this reason alone software development used to be very expensive and extra effort was required upfront to really pin down the full detail of all requirements.<br /><br />Ok, so punch cards may be a bit extreme so what about COBOL or something slightly more recent such as FORTRAN? Well, even these software development languages often required developers to book processor time on mainframes to test and debug their code. In these environments, extra effort in defining everything upfront mitigated risks as the development environments were very primitive by today’s standards.<br /><br />In the olden days this approach (Waterfall) was engrained into everyone who worked on the software development lifecycle, from Project Managers and developers, to end users. There were no other ways for decades.</p><p>Development environments back then were very different to what’s available today and many of the methodologies were born out of the development hurdles and technical constraints of the day.</p><p>Now contrast this with current development capabilities:</p><ul><li>Integrated development environments</li><li>Interactive debugging</li><li>Object Orientated Design</li><li>Real-time compilation and the ability to run software on the developers PC to get instant feedback</li><li>Continuous Integration</li><li>Automated Testing</li><li>Automated Deployment</li><li>Advanced release pipelining supporting rapid deployment</li><li>User / Developer collaboration enabling developers to develop systems WITH the end users</li><li>Object Relational Mapping</li><li>Design Patterns</li><li>Feedback loops measured in minutes / hours rather than months.</li><br /></ul><p>So, if the landscape is so unrecognisable now from how it used to be when Waterfall was the de-facto standard then why are lots of organisations still following an approach that is completely unnecessary and in most cases counter productive?</p><p>BECAUSE – the developers of yester-year are the Project Managers of today! They haven’t moved on from when <em>they</em> used to develop software. I’ve heard this a lot from PM’s who say they used to be developers – usually COBOL developers?</p><p>Singling out Project Managers is unfair as it’s more of a cultural thing across many levels of the organisation following conditioning over many decades. Another big contributor is the end users. The end users of yester-year are the senior business users of today and expect detailed definitions of all requirements up-front ‘because that’s the proper way to do it isn’t it?’</p><p>I’ve noticed this to be a particular problem in the UK Public Sector where they employ individuals – usually in positions such as ‘Business Assurance’ or ‘Project Governance Officer’ – to ensure project teams are capturing all requirements up-front and ‘doing things properly’. When challenged as to why it’s important to define all requirements in detail up-front, a common response is “because it’s the process” or “it’s the proper way to do it”. For decades these individuals and those around them have been told they must define all requirements up-front and be very detailed in their spec’s to reduce risk, so for them, this is the only way to develop software.</p><p>Another common misconception is that by not doing detailed up-front requirements capture we’re trying to avoid doing documentation. The reality is we’re not avoiding the documentation. I’ve regularly found that we’re not actually reducing the amount of documentation we produce - we’re just doing different documentation. Different in that we’re using other, more efficient, mental models to capture and communicate requirements or solutions such as site maps, wireframes, design mock-ups, user journeys, etc.</p><p>So, the biggest hurdle to finally putting Waterfall to rest is letting people know that its ‘ok’ to do things differently and developing software is not as difficult as it used to be – relatively speaking that is.</p>Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com2tag:blogger.com,1999:blog-4327759740825572923.post-16464235578138566692009-09-16T10:46:00.000-07:002009-09-16T11:41:02.348-07:00Agile perceptionsI've just presented at a conference titled "Agile in the public sector". I was there to represent the <span class="blsp-spelling-error" id="SPELLING_ERROR_0">NHS</span> Information Centre to talk about our experiences - good & bad - of introducing Agile practices into our area of the public sector.<br /><br />There were only a couple of similar case study presentations from other speakers who were actually doing this kind of stuff on the ground - in the public sector. The rest were what I class as <span class="blsp-spelling-corrected" id="SPELLING_ERROR_3">Evangelists</span> who talk about the ideals of Agile and basically <span class="blsp-spelling-corrected" id="SPELLING_ERROR_4">regurgitate</span> the usual Agile <span class="blsp-spelling-corrected" id="SPELLING_ERROR_5">idealism's</span>. Apologies to those guys if this sounds disrespectful. I'm sure all of them have had a lot of experience of introducing Agile practices but it seemed too distant and abstract from the usual day to day experiences.<br /><br />During the other speaker sessions I heard phrases like 'Agile is a journey' and 'Agile is a state of mind'. <span class="blsp-spelling-error" id="SPELLING_ERROR_6">ok</span>, great it's a state of mind but what can someone in the public sector do when returning to the office tomorrow to adopt this 'state of mind'? I really don't think the Agile community helps itself by presenting Agile as a mystical black art. Yes, they are right - it is a different mind set but where can individuals start when faced with introducing new practices into their organisation?<br /><br />I also felt there were a few mixed messages coming out of the session. The session was <span class="blsp-spelling-corrected" id="SPELLING_ERROR_7">supposed</span> to be about Agile in the public sector and yet the audience were faced with <span class="blsp-spelling-error" id="SPELLING_ERROR_8">DSDM</span>, Scrum, <span class="blsp-spelling-error" id="SPELLING_ERROR_9">XP</span>, <span class="blsp-spelling-error" id="SPELLING_ERROR_10">DSDM</span>, and <span class="blsp-spelling-error" id="SPELLING_ERROR_11">DSDM</span>. One of the audience made the point that it's confusing for those entering the Agile space to know which 'flavour' of Agile is right for them? I'm not surprised and I'm probably going to confuse matters further by saying they're all right and they're all wrong.<br /><br />Study all methodologies individually and take out and use the bits that best fit the needs of your project. Don't be afraid to experiment.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-42767148228279807022009-03-17T13:53:00.000-07:002009-03-17T14:00:31.680-07:00Agile by StealthI don’t know how many other people have witnessed the scenario where someone goes to senior management clutching a bunch of books and papers on Agile development, asking if they can do Agile on the next project? The usual response from senior management (who aren’t usually tech savvy) is a disguised fob off. In most cases they don’t even know what Agile development is so find it easier to dismiss. The types of organisations I’m referring to here are usually well entrenched in the bowels of PRINCE2 methodology. And no, this isn’t a dig at PRINCE2 as it has its place, and it can coexist with Agile approaches.<br /><br />Trying to release these strongholds from the shackles of PRINCE2 is extremely challenging. Many training and consultancy companies who evangelise Agile development talk about organisational transformation to enable Agile to happen. This can only work if cascaded down from the upper Escalon’s of the company and is perceived to be a big undertaking for most organisations.<br /><br />If you are lucky enough to work for a forward thinking organisation that values its employee’s opinions and is willing to embrace change then go for it and adopt an Agile approach to software development. Do it properly though and bring in external help if the size of your organisation warrants it. If however, you’ve tried to introduce Agile approaches to your organisation and you feel like you’ve been fobbed off then there is another way, Agile by Stealth.<br /><br /><br />Why do people ask permission to do Agile? Agile shouldn’t be taken as an all or nothing, or a one size fits all. Agile provides you with an extensive toolbox of approaches that you need to pick and mix from to suit the needs of your project.<br /><br />What I find is that if you announce in an organisation that you’re going to do Agile, you are instantly met with a lot of resistance. Why is this? Are they scared of the unknown or just resistant to change? Remember, most people don’t know what they like, they like what they know so any attempt to take them out of their comfort zone will be met with resistance.<br /><br />As I said earlier, look at Agile as an extensive toolkit and pick out what’s best for your project. You don’t have to jump straight into hardcore SCRUM, XP, DSDM, RUP, or any other methodology for that matter and go for a purist approach, which is likely to fail if you do. One bit of advice I’d give though is to make sure you read up on and understand the principles of Lean Software development. With such an extensive toolkit you risk introducing a lot of unnecessary wastage to your development life cycle, so only adopt what you need.<br /><br />I’ve listed below some of the practices that development teams can introduce from the Agile toolkit without the need for any management approval. These can sit very comfortably within a PRINCE2 stronghold and will drastically improve software quality and project success, even if you’re not doing Agile in the purest sense:<br /><br /><span style="font-weight: bold;">Automated Testing</span> – when I suggest this to development teams the first reaction is “we already do unit testing”, but unit testing is only one part of automated testing. Unit, functional testing using products like Selenium, security testing, and performance testing are other methods of testing to automate. This blog post doesn’t attempt to go into any detail on these approaches so go fire up Google and get exploring. If you’re asking yourself “why is automated testing important” or even “what is automated testing”, then again, go look it up on Google. It’s too big a subject to cover here.<br /><br /><span style="font-weight: bold;">Continuous Integration</span> – this should be one of your high priorities if you’ve got multiple developers on your project and CI can drastically reduce development time by removing the need for a final integration phase of a development cycle. It also weeds out all those annoying integration issues that usually result in an element of rework by facing up to the problems at the point they occur and still fresh in the developers mind. Doing a build upon check-in is an opportunity to run your automated suit of tests (see above) and alerting your development team when the build is broken.<br /><br /><span style="font-weight: bold;">Daily Build (Nightly Build)</span> – Many projects I work on have both Continuous Integration as well as a daily build in place. The reason for having both is that some automated tests can be extensive and take quite a bit of time to execute. For example, you wouldn’t want to run a performance test which lasts an hour or so for each check-in made to your source repository. The daily build is an opportunity to make a deployment to a staging server for stakeholders to view, preferably using an automated deployment process.<br /><br /><span style="font-weight: bold;">Short Iterations</span> – When defining Work Packages within the PRINCE2 framework, just define them as short Sprints but with a different label to keep it within the PRINCE2 framework. Other terms regularly used within PRINCE2 and MSP are staged deliveries.<br /><br /><span style="font-weight: bold;">Kanban, Burn up, and Burn Down Charts</span> – Project Management Offices and Senior Management constantly demand progress and status reports. Quite often this produces friction between developers and management due to the burden of collecting data. A great way to stem the tide of status requests and progress reports is to set up a series of Information Radiators. The Kanban system is a great way for multiple developers on a project to self-manage and to show exactly who’s working on what and what the status is. Burn-up and burn-down charts are great tools to represent the likelihood of the current development phase coming in to land on time. These methods have the distinct advantages over traditional time recording systems that they don’t put an admin burden on developers, tend to be more accurate, and are much more affective at communicating progress.<br /><br /><span style="font-weight: bold;">Test Driven Development</span> – the first mistake most development teams make with TDD is that they write unit tests for absolutely everything! Always keep Lean principles at the forefront of your mind and only write unit tests for complex or high risk areas of your code base. You can easily check for adequate code coverage by using code coverage tools such as nCover. Constantly look at ways of automating the testing of code and maximising test coverage. TDD isn’t just about writing test cases in nUnit before producing production code. It’s an approach that starts upstream with your Business Analyst. If your Business Analyst can learn to articulate requirements as a series of test cases then you’re well on your way.<br /><br /><span style="font-weight: bold;">Prioritisation of Requirements</span> – One of the core principles of Agile development methodologies is the ability to respond to change and actually embrace change. This is through short iterations and re-prioritisation of requirements at each stage boundary in close consultation with the customer. This usually results in developing the high priority requirements first to a releasable state and then take stock to either add or remove requirements before commencing with the next development iteration. Adopting a phased or staged approach to your project will open up the opportunity to revisit the requirements and priorities at the end of each stage. Most PRINCE2 projects that I’ve worked on already have a pragmatic phased delivery plan, but quickly lose agility when constrained by Change Control Boards and bloated governance. This is probably one of the more common areas of incompatibility between PRINCE2 and Agile. If you are in a position to establish and write your projects’ change control procedure then this is easy to fix. ;)<br /><span style="font-weight: bold;"><br />Communication & close collaboration</span> – having your key users or stakeholders working with your development team is another pillar of Agile. Good communication and close stakeholder management is a pre-requisite for any methodology. I always set up a staging server on every project and make sure the automated daily build deploys a working piece of software to the staging server so that all stakeholders can see the work in progress. This results in no surprises at the end of the development phase and ensures expectations are managed daily throughout the phase. If you’re not as brave as this (it does require a lot of caveats) then you should aim to review the software as its being built at least once a week with your key users and stakeholders.<br /><br />At the end of the day, delivering software is not easy and there’s no magic formula. No individual methodology can guarantee you success so it’s important to increase the size of your toolkit by learning about other approaches to software development, enabling you to adapt to the needs and circumstances of individual projects.<br /><br />The key message is this, no where in the PRINCE2 or MSP manual does it say “you MUST NOT use any other methodology, approach or tool with PRINCE2”. So, stop asking to ‘do agile’ and get on with it.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-25616600230541564502008-12-04T14:48:00.000-08:002008-12-05T05:42:15.973-08:00Time Recording and Wooden DollarsLet’s look at a typical project in an agency / software house that has adopted time recording. During this project a number of things happen:<br /><ul><li>The developers are constantly pulled off the project to support legacy apps, attend company meetings, and tend to various admin tasks. Only the time they actually spend on the project is recorded on the timesheet. All other tasks are booked to non-project codes.</li><li>Its winter time and a lot of time is lost due to high absence and sickness levels within the team (snivel). Again, only the time they work on the project is booked to it.</li><li>There are performance issues with a developer, resulting in quality issues and slow delivery. The PM makes a case with the project office that it would be unfair to have all this developers time booked to the project as he hadn’t received “value for money”. The PM wins the case and not all of the time spent on the project is booked to it.</li><li>Part of the project (as sold by the sales team) involves a developer getting up to speed with a new piece of technology which is critical to the delivery of the project. It could be considered R&D. The PM instructs the developer not to book the time spent on this task to the project as its “Training” and should be booked to the general company training code.</li></ul>The project is delivered late, BUT on paper the project is shown to have been delivered on budget and made a profit. The only problem is, in all of the cases above, the company is still absorbing costs so the fact that the time isn’t booked to the project means the project is dealing in wooden dollars. As this project is deemed to have been a financial success, this pattern is repeated on future projects. Scale this up to companies running many projects concurrently and this issue is hard to detect but massively amplified. Eventually, the company goes bust. A list of specific companies this has happened to and the evidence to back it up is available upon request.<br /><br />Time recording is a necessary evil in most software houses or agencies. A public sector client of mine is currently debating the need to introduce a time recording system to help with managing 60+ concurrent projects. I’ve come across the time recording debate many times and there isn’t a simple answer to whether you should or shouldn’t do time recording. The key thing to understand and be clear on is your purpose for introducing time recording to your organisation. Here are some reasons for doing time recording that I've heard some organisations use:<br /><ul><li>We want a way to quantify and record the amount of effort that goes into a specific task so we can improve future estimates. (excellent)</li><li>We want to <u>accurately</u> measure the P&L of individual projects. (difficult)</li><li>We want to use time recording to track progress. (valid but a very poor way to measure progress)</li><li>We need time recording to maximise staff utilisation. (very, VERY bad. See below)</li><li>We bill our clients on a time and materials basis so the time we enter goes straight into an invoice for the client. (good work if you can get it)</li><li>Time recording will assist us with resource planning. (possible, but better tools available to do this)</li></ul>Introducing time recording to your organisation will have a huge cultural impact. Below I’ve listed some of the good and bad points about time recording that should help you in forming a judgement on whether it’s right for your organisation:<br /><br /><strong>Bad</strong><br /><br /> - You have to police it resulting in staff feeling a squeeze from two different angles:<br /><ul><li>PM’s police what time is booked to their projects and fight like mad to stop time being booked to protect the budget. They have become very creative in their methods!</li><li>Line managers want to maximise the amount of billable time (wooden dollars) booked to projects and resist time being booked to non-project codes such as Training, Admin, Induction, Team Briefings, etc. (see utilisation below)</li></ul> - Line managers waste a lot of time chasing individuals to fill in their timesheets that could be better utilised elsewhere.<br /><br /> - It requires a lot of discipline from staff to update their timesheet daily. Daily updates keep the data more accurate and timely. If you have staff updating timesheets weekly then it’s highly unlikely that the data will be accurate.<br /><br /> - You may end up employing someone just to manage and police the time recording system.<br />Burden – time recording introduces a huge burden to your organisation and those who work within that environment. Any additional burden kills morale. If you constantly hound staff to complete timesheets then you will destroy their morale.<br /><br /> - If there’s a lot of resistance to time recording you may find some staff purposely incorrectly book time to undermine the validity of the system.<br /><br /> - Inaccurate filing and recording of time:<br /><ul><li>Some time recording systems I’ve seen don’t allow you to enter more than 37.5hrs per week. So how do you record overtime? This is a great way for some unscrupulous project managers to hide project overruns. </li><li>I’ve seen PM’s entering time on behalf of their team and miraculously making the figures fit.</li><li>Most people just make the time fit into what they feel are appropriate allocations they can get away with. They try booking it all to projects before having to justify why they’ve booked it to non-project codes.</li></ul>I’ve even come across PM’s who have stopped people from working on their project because “we don’t have the budget for you”. In these specific cases, the people offering help had no other work to do and could add real value. The real cost to the organisation would be the same as they’re paying for them anyway. The project would have been delivered earlier. The only cost to the project would have been in wooden dollars as the time recording system would report the project being over budget after they had recorded their time against it.<br /><br /> - Many KPIs (e.g. utilisation) within organisations are calculated using data from time recording systems. Given all of the above, this results in management decisions being made on wildly inaccurate data.<br /><br /><strong>Good</strong><br /><ul><li>Split charging of time for shared resources. If a developer is pulled of your project to resolve a support issue for a previous project then it’s useful to bill the time accordingly.</li><li>Time recording can help in measuring how long specific tasks take when used in the context of historical analysis and estimation of future work.</li><li>Time recording, if used correctly, has the potential to separate effort from schedule (requires a lot of discipline). In other words, if a task took 4 hours of effort but the elapsed time was 2 days then both of these metrics are valuable. This difference between effort and schedule is extremely common and yet rarely recorded. The elapsed time is usually recorded which means the project accounts for team meetings, sickness, or any other issues not normally accounted for in project estimates.</li><li>Time recording generates data. Data is great for producing lots of reports and pretty looking management dashboards.</li><li>It’s very easy to measure staff utilisation with a time recording system…..or so it seems.</li></ul><br /><strong>Utilisation</strong><br /><br />Most managers are trained and actively encouraged to maximise the utilisation of their staff. It makes sense right, as you don’t want staff sat around with nothing to do? It makes perfect sense that the more value we extract from our staff maximises the bottom line? Managers are often given a big fat pat on the back for reaching company utilisation targets, regularly in excess of 70%. Something that seems so obviously good actually has the direct opposite effect.<br /><br />Maximising utilisation is bad. Just in case you didn’t get that, MAXIMISING UTILISATION IS VERY BAD.<br /><br />To survive and be profitable in a software house the key is throughput. The more software you can get out of the door the more you can invoice clients. This is particularly relevant to fixed price contracts. I’ve come across very few outsourced software development projects charged on a T&M basis. The more you maximise utilisation the less chance you’ll have of having the right resource available when you need it. This incurs delays to the project or additional costs in bringing in contract staff or freelancers to cover. Many agencies in this situation experience the ripple effect where they start to borrow resources from other projects to get a project closed and invoiced. This cascades through all other projects. I’m not saying you should over resource so you can throw more bodies at a project, what I’m saying is you should over resource so you can improve your chances of having the right people available at the right time.<br /><br />Maximising utilisation impacts heavily on staff morale. Staff feel pressured to book all time to projects and not to morale boosting activities such as personal development, training, team meetings, etc. It stifles creativity, communication, and innovation.<br /><br />There’s an excellent book called Slack which covers the subject of utilisation in much more detail. The analogies it provides, which I quote far too often are:<br /><ul><li>If you run a motorway network at 100% - you get traffic jams</li><li>If you run a network connection at 100% utilisation – everything slows down</li><li>If you maximise utilisation within your agency – you print less invoices and go bust! (ok, this last quote is mine)</li></ul><br />I’m sure there are many project accountants out there who may pick fault with what I’ve written here and quote various accounting theories and approaches. I genuinely welcome their comment along with others as this has proven to be a highly contentious issue within organisations. Feel free to comment.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-8874495958280039982008-06-03T05:27:00.000-07:002008-06-03T05:30:52.001-07:00Software Development ResourcesI finally got around to pulling together many of the documents, templates, and tools I use on a regular basis into a static resource page. You can view this list of resources by clicking the following link:<br /><br /><a href="http://www.no-agencies.co.uk/Ian_Carroll_Software_Development_Resources_Tips_Templates_Tools.htm">Software Development Resources Page</a><br /><br />I've got a lot more to add over the coming weeks but hopefully this will be a big enough list to be useful.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-83110595499684721412008-03-31T14:34:00.000-07:002008-03-31T15:40:25.757-07:00Flow Time<span class="blsp-spelling-error" id="SPELLING_ERROR_0">ok</span>, so Flow Time isn't a new concept. It's been around for a very long time now. First published in 1987, <span class="blsp-spelling-error" id="SPELLING_ERROR_1">Peopleware</span> by Timothy Lister & Tom <span class="blsp-spelling-error" id="SPELLING_ERROR_2">DeMarco</span> completely changed my approach to managing software developers.<br /><br />Yet, Flow Time does seem to be a new concept to many development managers I speak to (and hence the reason for this post). As soon as I tell them what Flow Time is they instantly get it. It's not a difficult concept to grasp and most of them admit to interrupting developer Flow Time regularly.<br /><br />If you take a look around your development team - probably located in an open plan office - count how many of them are wearing headphones. A large percentage no doubt. What they're doing is getting into Flow Time.<br /><br />So if you still don't know what Flow Time is it's really simple. Have you ever been happily coding away only to realise that you've completely forgotten about the passage of time and it's now way later than you thought? Congratulations, you've experienced Flow Time. In <span class="blsp-spelling-error" id="SPELLING_ERROR_3">Peopleware</span>, the authors say it takes a minimum of 15 minutes to get into a Flow but takes seconds to come out of it.<br /><br />This means that <span class="blsp-spelling-corrected" id="SPELLING_ERROR_4">every time</span> you as a manager stops by a developers desk to "get a progress update", or anyone else telephones, emails, or interrupts them in any way, you're actually knocking the hell out of productivity. For every interruption it'll take them at least 15 minutes to get back to being productive.<br /><br />As a development manager I tell all of my developers to respect the Flow Time of others, i.e. if the headphones are on, do not disturb. I keep all team and project meetings to the beginning or end of the day. I encourage my team to check their emails at times to maximise Flow Time, i.e. beginning/middle/end of day. I tell them it's <span class="blsp-spelling-error" id="SPELLING_ERROR_5">ok</span> to turn on voicemail and respond at the end of the day. I also don't agree with hunt groups on phone systems or developers being interrupted to pickup someone e<span class="blsp-spelling-corrected" id="SPELLING_ERROR_6">lse's</span> phone.<br /><br />Go and buy a copy of <span class="blsp-spelling-error" id="SPELLING_ERROR_7">Peopleware</span> and when you've read it, sit back and observe your development team for a short period of time. I can <span class="blsp-spelling-corrected" id="SPELLING_ERROR_8">guarantee</span> you will make changes.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-42081198510608845132008-01-13T11:12:00.000-08:002008-01-13T12:28:37.404-08:00Home-shoring, Near-shoring, and Off-shoring - tips for technical leads with distributed development teamsFirst of all, a bit of definition - I define home-shoring as developers who are probably freelancers working from home as part of a geographically distributed team. Near-shoring is developers who are within a couple of hours of your timezone, and off-shoring is developers who are further afield. This blog post is NOT about Outsourcing.<br /><br />I've been managing and delivering software projects successfully using distributed teams for 5 years now. I've managed distributed teams from UK, Romania, North India (Deli), South India (Trevandum), and China (Beijing) on various types and sizes of projects. On the flip-side, I've been a developer in distributed teams on several projects, working remotely from my home in the UK and one project in particular where it was being run from Spain. With this experience I offer the following tips to other technical leads who may already be working with, or considering working with distributed teams from home or abroad.<br /><ul><li>Make sure all team members can contact each other at all times. As a manager I insist all team members appear online and can be contacted instantly via VOIP. Very invasive yes, but I can walk up to team members if they're based in my office location so it shouldn't be any different for remote workers.</li><li>Use Skype or an Instant Messenger application to see when other team members are online. Verbal communication is very important, don't let language barriers stop you from speaking.</li><li>It's very unwise (or even suicidal) to attempt a project using a distributed team without adequate source control. One other tip whilst on the subject of source control - locate the source repository closer to the physical location of the majority of developers. I saw a company once with the source repository in the UK but all their developers were in India?!</li><li>Use continuous integration - along with automated testing as much as possible. Ensure all developers are on the email list for when the build breaks.</li><li>Ensure all developers check in code regularly.</li><li>Invest some time at project inception on training all the team on how to work together effectively. Show them the desktop sharing tools, show them how to use Skype properly, make sure they understand the source control system and the automated build. You can do this easily using Webex or other conferencing / collaboration tools.</li><li>If you can, realign the working hours of the developers to synchronise the timezones. In other words, get the on-shore team to work early's and the off-shore team to work lates. It's important to maximise the amount of true collaborative working time to ease communication.</li><li>Give all team members a proper brief. See my earlier post on how to brief developers properly. Once you've written a work package, send it to the remote developer. Give them at least half a day to digest it. The next step is to do a desktop share and verbally step through the work package with them, line by line. During this desktop share session you'll flush out most of the questions and answers. Once they start development on the work package, make sure you review their progress every day via desktop share, reviewing their code and looking at the working software on their PC. </li><li>Here's some tools that I use with remote teams - <a href="http://www.unyte.net/">Lotus Sametime Unyte</a>, <a href="http://www.webex.com/">Webex</a>, <a href="http://www.skype.com/">Skype</a>. Actually, one of the coolest tools I've seen recently is <a href="https://lg3d-wonderland.dev.java.net/">MPK20</a> from Sun Microsystems. I'm not sure how effective it will be for remote teams but I can't wait to try it out on my next project!</li><li>If possible, bring the off-shore developers over to spend the first two weeks of the project on-shore working along side other project team members. This will serve as an excellent induction to the project which they can then take back with them.</li><li>If you have a significant number of off-shore developers on your project, bring one of them over to your offices to act as technical liaison for the duration of the project.</li></ul><p>I'm very keen to hear other peoples experiences of working with remote teams both as developers and as managers. Please post any comments on this topic so others can share your experiences.</p>Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-51243648672650394892007-12-09T14:34:00.000-08:002007-12-10T08:54:17.614-08:00Continuous Transparency - a new best practice?Continuous Transparency is the practice of giving your customer or key stakeholders direct access to the output of your daily build or continuous integration environment, in other words, your customer is able to see the work in progress (warts and all).<br /><br />For web applications you simply get your build script to automatically deploy the build to an internet facing server and send the URL to your customer. For thick client applications you give VNC or RDC access to a demo PC, usually located in your corporate DMZ, and send your customer the connection details.<br /><br />When you adopt this practice for the first time you must communicate to all stakeholders the following in relation to having direct access to the build:<br /><ul><li>What you will see in the build is work in progress. It is normal for untested software that is in mid-development to crash or give unexpected results. Please do not log any calls or be alarmed if the software crashes or is partially unavailable or completely unavailable when you try to access it.</li><li>You must not use the build for demonstration purposes within your organisation as it may change significantly before the final release and may not be available when you come to demonstrate it. You also run the risk of setting the wrong expectations should the software fail or change in the future.</li><li>Placeholders will often be used where content or functionality is not yet available to provide “scaffold” for the application.</li><li>What you see in the daily build does NOT constitute an official release.</li><li>All previous data is removed each time the build is deployed. </li></ul><br /><strong>Advantages of Continuous Transparency</strong><br /><ul><li>Builds an enormous amount of confidence with the customer and creates a very strong relationship as they can see tangible progress and feel constantly engaged.</li><li>Enables you to share problems with the customer in real-time. The most common problem is having an overly optimistic (unachievable) schedule. The customer can usually gauge the overall progress of the development and realise that you can’t complete all functionality on time. They actively help you to de-scope the solution to hit their deadline.</li><li>Focuses the developers’ minds when they know all stakeholders are watching their creations on a daily basis and improves quality upstream.</li><li>Entirely removes the risk of any surprises to the customer when the first release is made, where they would have traditionally only seen the software after many months of development.</li><li>Flushes out change requests or fundamental requirements issues earlier on in the development life cycle. Better to find out earlier before project budget is burnt.<br /></li></ul><strong>Disadvantages of Continuous Transparency</strong><br /><ul><li>If your project has major resourcing issues (I’m not talking about the odd day of sickness or annual leave) then your customer will be able to see an unexplainable lack of progress.</li></ul><br />I have operated Continuous Transparency on all projects I’ve run over the past 4 years and it’s always been a great success.<br /><br />Everyone I’ve introduced it to automatically gives me a look of horror followed by "showing the customer untested software or airing our bugs in public is ridiculous", or "but doesn’t it give the customer a chance to sneak in changes?" But once they try it and reap the rewards of success they say they will never go back to how they used to do software. Most importantly though, is all my customers have said “why don’t all our suppliers operate like this.”<br /><br />I’m interested to hear comments from anyone who’s already operating this approach or is concerned or sceptical about using it.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-23003194041041839802007-09-30T04:25:00.000-07:002007-10-04T04:49:43.451-07:00Briefing DevelopersFor some time now, I’ve been meaning to write a post on “briefing developers properly”. The difficulty I’ve had is articulating it in such a way that it provides some real tangible advice that can be of immediate use to Technical Leads and Project Managers. The more I think about it, the more I realise I could write an entire book on the subject. There isn’t simply a one-size fits all <em>Developer Briefing Template.doc</em> that you simply fill in the blanks.<br /><br />Many attributes affect which approach you use to brief a developer. Project type, project size, team size, and schedule are all attributes you need to think about when considering the most appropriate approach. For example, a small Flash based multimedia project would probably be best suited to a simple story board. A web site should have a site map as a minimum. A web application could require a more detailed work package incorporating UML.<br /><br />What ever approach you take here’s some key points to consider when writing a brief:<br /><br /><br /><ul><li>A verbal brief isn’t a brief. It must be in some kind of a written form. </li><br /><li>Piecing together the brief from a large email thread is the wrong type of written brief!</li><br /><li>Complementing the written brief with verbal communication is acceptable.</li><br /><li>Get the developer to play back the brief to you to give you the confidence they’ve understood it.</li><br /><li>Don’t be too prescriptive in the brief as you still want developers to use their expertise in coming up with solutions. </li><br /><li>Reduce the risk of over-engineering or misinterpretation of specs by putting extra effort into the test & acceptance criteria, and review their work regularly.</li><br /><li>Don’t just give them the document to get on with. Step them through it and get them to explain it to you.</li><br /><li>Don’t assume that something that is obvious to you is obvious to them. Explain everything, even if you risk insulting their intelligence.</li><br /><li>Keep documentation lightweight. Remember, “a document isn’t finished when you can’t think of anything else to put in it, it’s finished when you can’t take anything else out of it.” (<em>Steve McConnell</em>).</li><br /><li>Avoid writing a paragraph containing multiple business rules that may result in some rules becoming overlooked. Separate out each business rule into an itemised list that can be ticked off when completed.</li><br /><li>Pull together a work package that not only contains the brief, but also contains any assets or test data the developer needs to complete the work.</li><br /><li>Get the developer to provide you with a work breakdown structure for the task at hand, along with estimates for each task. When the developer goes through this exercise it shows they’ve really thought about what they’ve got to do.<br /></li></ul><strong></strong><strong>Test & Acceptance Criteria</strong><br />I can’t emphasise enough how important it is to define test & acceptance criteria for the developer. You can do this in a number of ways but I tend to generate some test data for “input” into the system and specify how it should result in its “output” state. If you do have a test team, get them to contribute to this section.<br /><br />Your T&A criteria should exercise the non-functional requirements as well as the functional requirements. So, if you’ve specified 100,000 records as the warrantable limit of your system then you need to specify this in the T&A. You should also provide this test dataset in the work package for the developer.<br /><br /><strong>Work Packages</strong><br />In many organisations I’ve worked for, it’s very rare for a developer to do everything in the software lifecycle themselves. The organisations are usually made up of teams of Business Analysts, Graphic Designers, Producers, PM’s, Developers, and Testers. This results in a collection of documents looking at the project from different perspectives that the developers have to implement.<br /><br />My personal preference when briefing developers is to create what I call a Work Package. This work package pulls together the relevant sections from the collection of documentation to deliver a specific piece of functionality. The following diagram should give you some ideas as to what could be included in a work package:<br /><br /><img id="BLOGGER_PHOTO_ID_5117442927160449650" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqrk0j6-ZNMwVH0S3rRFfEXGjAkLJph2OcO_r0Iumz67k6mxMlzaS9ss38Xo7koav-er45vxyvLbEIsF6Ypkk8IE40g-Krfoaw4GIQkvcizHWA0dAJXDIIU_CJI41Ae_q3XkpKkJueoqw/s400/WorkPackage.jpg" border="0" /><br />I often get asked how big a work package should be. This obviously depends on the size of the project, but from the point at which the developer starts the work package to the point where it’s finished (see previous post on what is classed as finished!), should be a minimum of 1 week. I’ve written many work packages that take 20-30 days to complete so there are no strict guidelines on how big it should be. I have found though that writing a detailed work package for small tasks of a few hours simply doesn’t work. Quite often in these situations I find a whiteboard or flipchart perfectly adequate, but the important point is that it’s being written down.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-14678682903586892272007-08-09T06:19:00.001-07:002007-08-09T06:37:54.035-07:00Is it finished yet?When developers say they’ve finished a work package, what does finished really mean? In the majority of cases, it’s not finished.<br /><br />Ok, so this isn’t always the case. I’ve worked with some great developers who when they say they’ve finished, they really have delivered a finished work package which goes through the test dept with nothing more than a couple of minor queries on interpretation of the spec. Rock solid code and always delivered on time.<br /><br />I consider a work package complete when the developer is confident the <strong>robustness</strong> of the product is good enough to stand up to rigorous testing (examples below), the deliverable is <strong>functionally complete</strong> with a tick against every item in the work package, and the <strong>code quality</strong> is of an acceptable standard. If a developer gets these basics right it’ll be a monumental leap forward.<br /><br />First of all, a developer needs a solid spec to work from. This doesn’t need to be Encyclopaedia Britannica in proportions but it must contain a few key ingredients – the main one being Test & Acceptance criteria. I’ll be covering how to brief a developer properly in a forthcoming post but don’t worry as you can still apply the rest of this article.<br /><br /><strong>Robustness </strong><br />This is generally my attempts to break the application to see how easy it is for a user to break it and see how gracefully it fails. I pull the rug from under the application in several different ways to see how recoverable or gracefully it fails. What I’m talking about here really is how well the overall exception handling strategy has been implemented. This is still a key area that is regularly missed by developers. Testing the robustness is a good measure of how well the application has been written. So for example, on web applications I’ll bypass client side validation using something like <a href="http://www.fiddlertool.com/fiddler/">Fiddler</a> and inject all sorts of evil data into the application to make sure data is being validated server side as well as client side. As a developer, if you treat all input as evil, you’ll write more robust applications. When we talk about input here, I’m not just referring to user input. Its common place these days, especially with service orientated architectures to have other routes for data to enter your application which you need to treat as “evil input”. For more information on writing secure code read the <a href="http://www.owasp.org/">Open Web Application Security Project (OWASP) guidelines</a>.<br /><br />A common issue I come across usually arises when different developers are working on different tiers of an application, i.e. the UI developer just calls methods from the Biz layer and from that point on it’s the other developer’s problem (chucking it over the wall syndrome). But the common bug here is data integrity. I always test this by putting uniquely identifiable data into each form field (up to the max length) and then check it’s been mapped correctly to the database with no concatenation. If there are any issues I raise them there and then and <strong>own</strong> the issue until it’s resolved, no matter which team or developer is responsible for resolving it.<br /><br /><strong>Functional Completeness<br /></strong>I often hear PM’s and business analysts complaining that developers don’t follow specs or they’ve implemented it wrong. The common responses to this from developers are “oh yeah, I didn’t spot that one”, or “I thought that’s what it meant”. This is an area that can be improved by briefing the developer clearly and having peer reviews in place. Again, look out for my forthcoming post on briefing developers properly.<br /><br />Unfortunately, I’ve come across many sloppy developers who adopt an attitude of “it doesn’t matter as anything I miss in the alpha release can be picked up in the beta”. For some reason, some developers seem to be coding as if it’s a proof of concept, or a dress rehearsal (“I’ll come back and complete all the detail later as I want to get it functionally working first”) and skip the important detail, and never go back and finish the detail. Some bad developers I’ve encountered stick “finished” work packages into test to buy themselves a couple of days rest. I’ve even heard several developers say “I’ve put it into test so they can give me a list of things I’ve yet to do”. When you have a developer with this attitude, it’s not a training issue or a mentoring issue; it’s a HR issue that needs dealing with immediately by reassignment, possibly to another company. (<em>Peopleware, Tom Demarco & Timothy Lister</em>).<br /><br />Developers have said to me “so if we’re doing all this testing what do the test team do?” or “isn’t this what we have testers for?”. Getting over the project finish line will not happen if you get stuck in a continuous test and fix cycle with the test team. Each iteration of this cycle is prohibitively expensive and kills project budgets.<br /><br />Every time you submit a deliverable to a good test team they will, recreate a “clean” environment to test on, run through their test scripts, write up bugs in the bug tracking system, and handle all the communication around these activities. In essence, every time you submit something to test, you are in fact triggering a huge amount of effort (project budget) to be burnt. This test team effort does not directly improve the quality of the product, it just gives you a measure of what level of quality the product is at; in the same way that a set of scales tells you how much you weigh – they don’t make you lose weight (<em>Steve McConnell, Software Project Survival Guide</em>).<br /><br /><strong>Code Quality </strong><br />I’ve seen many company coding standards in the form of a 60 page plus coding standards document that takes a developer at least a day to read and then gets forgotten about. These paper based documents are almost impossible to enforce in a commercially viable way. They quickly become out of date as the Microsoft platform moves forwards. These documents really aren’t necessary. What you need is some basic tools and a whole load of common sense. In fact, most of the coding standards documents I’ve seen, basically look like a rules export from FXCop. FXCop is free and can be incorporated into your daily build. If you do have some specific coding standards that FXCop doesn’t cover then write yourself an FXCop rule for it! This is just one aspect of code quality though. Other areas are, how well it’s been documented, how much unit test coverage you’ve got, and is the code at a low enough level of complexity . These are the main aspects of code quality that I look for in a deliverable. Click <strong><a href="http://del.icio.us/yandaq/tools">tools</a></strong> in my tag cloud for further details on Code Quality tools.<br /><br /><br />I hear the uninitiated saying “So if I have to do all this extra stuff to get a work package to the standard that you consider finished, it will take me twice as long!”, wrong! - by adopting a test driven attitude to development (TDD) the good developers who I mentioned at the beginning of this post deliver high quality quicker. For more information and an in-depth look at TDD visit the blog of <a href="http://danbunea.blogspot.com/">Dan Bunea</a>.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-87752654243969964822007-07-05T00:57:00.000-07:002007-07-05T13:10:32.581-07:00Why I hate Gantt chartsOne of my pet hates is Project Managers (PM's) living their lives in Gantt charts or spreadsheets. I've seen many projects over the years where PM's have got to the end of the project without ever seeing the actual delivered software! Incredible I know. I'm flabbergasted every time I see it and I still see it regularly. In fact, I think it's on the increase.<br /><br />They usually get their progress reports from developers via MS Excel in the form of hours to complete per task or some other kind of subjective guess. They then merrily update their Gantts in complete ignorance of what's really happening and get on with writing their progress reports. It's a real coincidence that the plans nearly always look rosy in these situations ;)<br /><br />On some occasions I've had to force PM's to look at the software to gauge for themselves how complete it is. Interestingly enough, what they consider complete rarely matches the developers idea of complete, which in itself introduces another key review point.<br /><br />My message to PM's is, stop hiding behind project plans and get under the skin of the software to form your own judgement of progress.<br /><br />My message to developers is, the only real measure of progress is tangible software that PM's can see and interact with, so make sure you're constantly in a position to demonstrate this.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com3tag:blogger.com,1999:blog-4327759740825572923.post-91328516770567609782007-07-03T00:50:00.001-07:002007-07-03T01:44:15.035-07:00An easy way to improve code qualityCyclomatic Complexity has been around for a long time and yet many developers are still unaware of it. Cyclomatic Complexity is the measure of code complexity. It's just one aspect of code quality but I've found it's impact to be massive when used daily within the software development life cycle. Cyclomatic Complexity Analysis basically counts the number of decision points (e.g. If's, elseif's, Case's, nesting levels, etc) in source code and gives you a rating. These ratings can be assessed as follows:<br /><br /><table valign="top" cellspacing="0" cellpadding="4" border="1"><tbody><tr><td><strong>Cyclomatic Complexity</strong></td><td><strong>Risk Evaluation</strong></td></tr><tr><td>1-10</td><td>a simple program, without much risk</td></tr><tr><td>11-20</td><td>more complex, moderate risk</td></tr><tr><td>21-50</td><td>complex, high risk program</td></tr><tr><td>greater than 50</td><td>untestable program (very high risk)</td></tr></tbody></table><br />The reality is that the most complex areas of a code base attract the most bugs and as it's complex code it's harder to fix (and costs more!). <br /><br />About 3 months ago I introduced it into the daily build on all projects at my company so that the build fails if code is introduced into the build with a complexity rating greater than 15. Initially it took a while for the development team (34 developers) to make it part of their daily routine but it has paid massive dividends. We've noticed a sharp decrease in the number of bugs found in the testing phase, and maintenance of the code base's have eased dramatically. <br /><br />If a developer can't get the complexity down below 15 then it's put out for review to other developers. There are occasions when it's truly not possible to reduce the complexity due to performance tradeoffs but at least those important decisions are being handled in the correct manor.<br /><br />Out of curiosity I ran the analysis tool over some past projects to get a feel for some kind of baseline to measure improvements against. One particular project reported a maximum complexity of 536!! I thought the analysis tool was broken until I dove into the source code and found a single method containing over 3000 lines of code, consisting mainly of if, elseif, if, elseif, etc. Also, the deepest level of nesting in this method was 24! Only a complete nutter could have written this!<br /><br />So in summary, my advice to you as a developer is anything you write, analyse the complexity and simplify accordingly.<br /><br />There are many other tools available for analysing code complexity such as IDE integrated plugins from Developer Express to name just one. Find the one that's right for you and use it.<br /><br />The best tool I found for analysing complexity is <a href="http://www.campwoodsw.com/sourcemonitor.html">Source Monitor</a>. It's good for two reasons; you can run it as part of your daily build & smoke test, and it's free! It works with all the mainstream languages such as C#, VB.NET, Java, and we've also managed to get it to work with Actionscript 2.0.Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com1tag:blogger.com,1999:blog-4327759740825572923.post-38282464534587978102007-07-01T07:46:00.000-07:002007-07-01T11:38:10.956-07:00Agile - here's my two pennies worthNot a week goes by without hearing someone say "we're taking an Agile approach to this project". In most cases, the Agile approach means "we're making it up as we go along". I'm not going to create yet another blog on the pros and cons of Agile. Instead I'm simply going to point you in the direction of a great video presented by the inventor of SCRUM, who let's face it, should be able to explain it better than anyone.<br /><br /><embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=-7230144396191025011&hl=en-GB" flashvars="&subtitle=off"> </embed><br /><br />Even if you can't adopt the full SCRUM approach you should still be able to pick out a few gems from this video. Developers should pay particular attention to the section on cutting quality!Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-25245952497622189502007-06-29T07:44:00.000-07:002007-06-29T08:21:36.441-07:00SolutioneeringWhen I’m recruiting developers, what I’m actually looking for is Solutioneers. These are developers who consider “getting things done” as one of the problems they need to solve. For example, if another part of the project team is holding up their work, this isn’t an opportunity to kick back and grab some slack time. This is a problem that needs solving. May be the simply solution here would be to walk around the office and get the blockage cleared. I here non-solutioneers saying “but that’s not my job” or “I didn’t want to step on anyones toes”. Finishing a project on time must be a Solutioneers primary goal and as such is always willing to "solve this problem" by rolling up their sleaves and getting stuck into any aspect of the project. Solutioneers take ownership very seriously and often lose sleep at night over particular aspects of project delivery.<br /><br />To be dynamic enough to solve problems they need to keep on top of what’s happening around the industry, and constantly pushing their own intellectual capacity and technical abilities. These Solutioneers are avid bloggers who not only write blogs but also see blogs as a valuable source of knowledge. They spend their daily commute glued to technology podcasts and spend lunchtimes scouring the web for quicker and better ways of developing software (these are the guys who keep sending emails saying, “hey, have you seen this!”). Almost certainly they'll have what is approaching an enterprise class data centre in their home to enable them to tinker in the evenings and weekends. Solutioneers posses an almost unhealthy passion for software development and never rest on projects until they’re over the finish line, so a sense of urgency is one other facet here.<br /><br />You may be thinking that outright Solutioneering can be very hazardous in a commercial project environment and spits of perfectionism which can easily blow project budgets (over engineering syndrome or paralyses by analysis!). This is yet another problem for a Solutioneer to overcome. Solutioneers are experienced enough to make a balanced call on trade-offs, i.e. I know the purest approach to a software problem, I know the quick and dirty approach, but what’s the risks associated with trade-offs from either end of the scale?<br /><br />Solutioneers have to be good communicators and be very personable, friendly, and approachable. But most of all they must posses a good sense of humour.<br /><br />Oh yes, I forgot, and if they know the .Net Framework, C#, SQL, and most Microsoft technologies and platforms then that also helps! ;)Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0tag:blogger.com,1999:blog-4327759740825572923.post-44991899421450077682007-06-29T01:53:00.000-07:002007-06-29T02:28:46.493-07:00The importance of defining non-functional requirementsYou wouldn't believe the amount of projects I've come across where nobody on the project team has established what the non-functional requirements (<span class="blsp-spelling-error" id="SPELLING_ERROR_0">NFR's</span>) are. If you're reading this and thinking "what the hell are non-functional requirements" then this very brief introduction to them is for you. If you're already familiar with <span class="blsp-spelling-error" id="SPELLING_ERROR_1">NFR's</span> then read on anyway as there may be a few nuggets in here for you that you don't already know.<br /><br />So, non-functional requirements (sometimes referred to as Software Quality Attributes), in the simplest terms define performance, scalability, capacity, resilience, and many more attributes of the software being delivered. The best way for me to describe why <span class="blsp-spelling-error" id="SPELLING_ERROR_2">NFR's</span> are so important is to share with you a few experiences. Here's one experience to demonstrate the point:<br /><br /><p>A web application is designed, built, tested, passes <span class="blsp-spelling-error" id="SPELLING_ERROR_3">UAT</span>, and deployed. The customer is happy for the first 6 months as traffic levels have been low. Over time the traffic levels rise (from 30 user sessions a day, to over 2000 sessions a day). The web site starts to crash regularly, the customer is very unhappy with the "quality" of the delivered software and wants it fixing. Well, you can see where this is going already. The answer to this seems obvious, why didn't the supplier agree traffic levels with the customer up front and design the solution appropriately?</p><p>Well, this isn't always as easy as this. Did the customer even anticipate such high traffic levels? Is the customer techno savvy enough to care about such things as this is what they pay you for isn't it? Shouldn't you have made some assumptions in this case? </p><p>When I'm dealing with a customer who isn't techno savvy and doesn't know what their traffic levels are going to be, there's always the temptation to design for a large number of users, i.e. design BIG. Unfortunately, going large on these decisions costs more money to do and very quickly you become uncompetitive and could potentially end up with the customer walking away and cancelling the project before it's even started. The best thing to do in these circumstances is to agree with the customer an affordable level of scalability and then <em>warrant the system to this level</em>. Basically, agree that your design can handle say 100 concurrent sessions, and do your internal performance testing to this level. In this situation you're only warranting the system to 100 sessions and if the customer exceeds these limits then the solution may continue to operate comfortably but you won't fix any issues that occur without charging for it.</p><p>For further reading on the subject of <span class="blsp-spelling-error" id="SPELLING_ERROR_4">NFR's</span> here's a link to an <span class="blsp-spelling-corrected" id="SPELLING_ERROR_5">extremely</span> thorough list of <span class="blsp-spelling-error" id="SPELLING_ERROR_6">NFR's</span> that I use daily! <a href="http://www.systemsguild.com/GuildSite/Robs/Template.html"><span class="blsp-spelling-error" id="SPELLING_ERROR_7">Volere</span> Requirements Specification Template</a></p>Ian Carrollhttp://www.blogger.com/profile/05805934919180543615noreply@blogger.com0