Friday, 13 June 2014

non-functional code what I immediately think of when I′m asked to work with ′non-functional requirements.′ If that′s what they want, I am only too willing and definitely more than capable of satisfying the request and have proved this many times in the past.

Seriously, though, the way we are presented with these so-called non-functional requirements is amazing, as is the range of them. One of the most common ones is, ″It must be fast!″ Well what does that mean? Programmers are sometimes accused of being pedantic and selfish about what functionality they will let you have from a system but the other side of the coin is the miserly customer, the one who is unable, or refuses, to explain the true extent of the requirement. Fast is a relative term. We need to ask the customer, ″How will we know when it is fast enough?″ In other words, we need to quantify it so we can write a test for it. Tests are how we know that we′ve completed the task and can go on to the next one, or go home. Only when the tests are passing do we know that we are finished and the software is running the way the customer wanted it to. Anything else is merely guesswork. I can picture the scenario now, with the developer repeatedly demonstrating the software to the customer only to be told to go away and make it faster and faster, again and again.

Feasibility is a major consideration too. I once worked on a project where the customer requested (demanded actually) that there be no more than a 35 milliseconds delay between one part of the system and another while under load. Unfortunately, when we timed the original system that we were only building an add-on for, we found the elapsed time was already 40 milliseconds. Getting it down to 35 could probably only have been achieved by rewriting the whole thing from scratch, if at all. Luckily, and after discreetly pointing out to him the incongruity of his wishes, the customer was able to see the funny side of his over-enthusiastic demands and relaxed the lag time to 50 milliseconds, which was easily achievable.

It was easily testable too. We already knew the performance of the existing system, so it was simple to calculate the longest delay our add-on should introduce, i.e. 10 milliseconds. Anything more and we had failed. It′s not difficult to introduce tests to demonstrate timings; there are even profiling applications out there that can do it for you. Malcolm, the manager of this particular project, had his own pet profiling application that he was familiar with and wanted to use it on this project. He felt that since he′d been on a training course for the product, he might as well put his knowledge to good use. His suggestion was that once a week or so, he would; set the software up on a machine, insert timing marks into various bits of the code, run the profiler and then distribute the timing diagrams that it produced around the team.

All well and good but I felt that, at a week, the feedback loop would be a little too long and asked if we could automate this as part of our test harness. Then it would run every time a developer ran the unit test harness prior to integration and we would know that our timing test was failing before we put the code in the codebase rather than some time after. The biggest obstacle to that was the cost of licenses, this particular product would have required each development workstation to have its own license at a cost that we could have probably hired two more developers for a year for.

An alternative, and the one that we decided on, was to insert our own timing marks inside unit tests. It′s easy enough to do using standard C++ system timing calls and I′m fairly sure they′re available in most other languages too. Get the current time to the nearest millisecond, call the functionality under test and then calculate the elapsed time. We knew what the boundary time was so anything under that was a pass and over was a failure. Because we were practising continuous integration with hourly automated builds, we would know almost immediately if we had transgressed this particular constraint. There was no need for everyone to have a license for the profiler and no need for anyone to use it unless the test failed.

″Well now,″ I hear you say, ″That′s all very well and good for testing whether or not you′re complying with the customer′s requests but doesn′t good practice dictate that you design for speed in the first place?″

This, I think, is a hangover from the early days of programming when processing time was expensive and programming time was cheap. Things are different now but there still seems to be an awful lot of people out there who haven′t noticed this shift in paradigm. We all know processor speeds have been doubling every few years for decades, surely I′m not the only one whose wages haven′t been doing the same? Still, at every shop I go to, there is at least one hard-liner that insists of poring over every line of code he produces, seeking to wring the very last microsecond of performance out of it. Probably dreaming of winning the Obfuscated C award (is that still going?). I′m sorry but in today′s era of optimising compilers, this counts as gold-plating. I′m not saying there are no occasions when speed is important, I′m just saying these are very few and they are becoming fewer and fewer as processors get faster and more powerful. I′m also greatly aware that compilers are usually much, much better than humans at code optimisation.

So my answer is not to try to code for speed but code for quality, which to me means simplicity. Concentrate on getting the code working and refactored first. By working I mean passing all the tests you and the customer can think of throwing at it and refactored so that it has the simplest design possible, with no redundancies or duplication and still passes the test. When and only when, it fails the timing test, you can run it through a profiler and let the profiler tell you where the bottlenecks and hotspots are. The profiler will make a much better job of identifying the areas that need improvement than a human possibly ever can. Starting from a simple design will make it so much easier for you to redesign and having tests will make sure that it′s still functioning correctly. Make it work, make it right, make it fast!

It does make me wonder though, when these shifts in reality are not perceived, or are ignored, sometimes even denied, by members of our own community. We′re supposed to be at the leading, if not bleeding, edge of technology and yet so often try to stick to practices that have long been made redundant by changes in technology.

I remember giving a talk on the quality over speed subject to a development team at a very well-known insurance company last year. I was just at the bit where I recommend coding for quality rather than speed when the development manager jumped out of her seat and interrupted my talk, calling for her developers to ignore every word I′d said and, in future, ″Design all of your code to be fast.″

So speed, the ′make it fast′ syndrome is the most common non-functional requirement that comes my way. The next most popular (with the customer, not me) one is scaleability, usually manifested as; ″Make it scaleable.″

This one really throws the developers sometimes because they suffer from the ′3 numbers′ problem. That is the only numbers they recognise are; zero, one and infinity. So when asked to make it scaleable, they know they won′t be dealing with zero transactions or users, it′s not one either, so it must be an infinite number of users or transactions that they need to be able to handle. They will spend weeks, if not months, trying to figure out how to make the system handle, maybe not an infinite number of users, but at least the number of human beings alive today. More gold-plating!

Plainly this is very rarely the case and the solution is similar to that of the speed issue. Give them an appropriate number so they can write a test that involves exercising the system in a test situation with that number of users, or shows it shares its load properly over that many machines in a cluster. Given the tests, we will always know when we are complying and when we′re not. With scaleability my approach is make it work for one instance first.

There are many more of these so-called non-functional requirements and yet all of them are about functionality. They may not individually relate to single features but all of them are about how the application functions and all of them can be tested.

One I really hate and that can′t be tested automatically is ″Must be easy to use.″ You can guarantee that the customer asking for this one is the guy that insisted on having a feature list longer than War and Peace, with multiple configurations for each. Ease of use, or usability as it′s popularly known, shouldn′t really fall within the programmer′s remit, it′s something they are notoriously bad at anyway. This is something best tackled by Interaction Designers before the programmers start coding. In reality, it gets tagged on at the very end when the customer suddenly realises the user interface is too complicated as a result of all those finicky little widgets he absolutely insisted on having.

As my colleague, the French developer and Author, Laurent Bossavit, says, ″The distinction between functional and non- functional requirements is useless. All types of requirements stem from a misfit, a difference between a perceived current reality and a desired future reality. Articulate the difference; if its effects can be tested, then you can make it a requirement. In many, many cases, the test also allows for total or partial automation.″

The most important thing is to get the information at the appropriate point in the project lifecycle. It makes things much easier if the customer tells you, ″by the way it has to support 15,000 users a day across 4 continents″ on day one, than if he tells you the week before release is due. This is where experience comes in, knowing what questions to ask the customer, if it′s a client app, is it stand alone, or does it share data with other users, if it′s a server app, how many concurrent users, etc.

Last but not least, I swear that the next time a customer requests that his application, ″Should be pretty,″ I will fetch my ugly stick and batter him with it, or maybe send it to Trinny and Suzannah for a makeover.

First published in Application Development Advisor

Thursday, 13 February 2014

agile pontypridd

Pontypridd must be just about the strangest town in the universe. Apparently, there are houses there with a very strange geometry, so strange that some of them may even be only possile in a multi-dimensional parallel quantum universe.

The proof for this is simple. Whenever you meet someone from Pontypridd, mention Tom Jones, the famous singer. You will immediately get a response along the lines of, "I (or my mum/dad grandmother/grandfather) used to live next door to him (or his mum/dad, etc, etc)"

This has led many to believe that PontyPridd consists of a couple of many-sided houses belonging to the Jones clan in the middle of the town with all the other domiciles arranged in a circle around them. Obviously, the number of houses next to these necessary to support the many claims of next-dooredness cannot be satified in the three dimensions of normal space, so we may have to imagine the town exists only partly in normal space and partly in that multi-dimensional parallel quantum universe we mentioned earlier. All I can say to the Ordnance Survey team and the town planners is, "Good luck with that one!"

This brings me onto XP and I am talking about eXtreme Programming, not the Windows operating system. The reason I mention it is because, as a member of many online agile discussion groups, I often meet (in an online sense) people that claim 'I was one of the first people to practice XP in the UK' or 'I was a member of the first XP team in the UK.'

Curious, isn't it? Did XP really break out in such a multitude of places in the UK simultaneously? Or was there one gi-normous XP team that everyone was a member of?

My guess is that when XP first arrived in the UK, there were maybe one or two teams practising it in this universe but obviously an infinite number of others being the first to practise it elsewhere in the multi-verse.

Now I'm wondering if it's the recent breakthroughs in quantum computing that has let all these parallel pioneers slip into our universe and if there is any way of getting them to go back?

Monday, 13 January 2014

agile mandate

XYZ were a digital agency and over the years had done many software projects for their customers with varying degrees of success. After learning that many companies were having great success with Agile processes and noticing that even the UK government had decided to adopt those ways of working, the directors had realised the use of these new techniques would improve the performance of their own company. To that end, they had issued a mandate to the project team that by the end of the financial year, they had to have performed at least one Agile project. By this time next year, all projects needed to be Agile.

So it was that Colin, our intrepid consultant, found himself in the office of Richard ‘RJ’ Jones, head of XYZ’s Project Office. RJ had contacted Colin so he could get the training and coaching he needed for his team before they started their pilot Agile project.

“Tell me,” said Colin opening the conversation, “how big is your team?”

RJ though a bit before responding, “We have a team of about fifteen project managers, maybe twenty or so business analysts and half a dozen architects”

Colin looked at him quizzically, “but what about the engineers, the coders, and the test analysts? How many of those do you have?”

“Ah! I see your confusion,” he replied, “We don’t have any engineers of our own. We outsource all our development and testing work to best-of-breed suppliers in India. We haven’t done any of our development for years.”

He continued, “Three of the developers for this project are an outsourcer’s head office in Chennai; the other two are in a subsidiary office. Again, they’re in Chennai but they’re about forty-five minutes apart. The two-man QA team is in Mumbai but they work for a separate supplier company and, again, have their own office.” He looked at Colin, “Is not having our own engineers a problem?”

“It’s not so much that you don’t have your own team, although, admittedly, that is a problem. The bigger issue is where everybody is located,” said Colin, “Agile is based on a set of principles and one of the most important of those principles is that face-to-face communication is the most effective. You’re not going to be able to carry out face-to-face conversations with people halfway round the world.”

RJ had a frown on his forehead, “I hope this isn’t going to be a big problem. There is no way I will be able to get everybody on the same continent, never mind in the same room. I just don’t have the authority; I have no say at all in the working practices of our outsourcing partners. I was hoping you would be able to just give us some training and maybe follow that up with some coaching.”

Colin smiled at him, “It’s not quite that simple. Agile isn’t something where you can just attend a class, get a certificate and all of a sudden you become Agile. Agile demands real change.”

RJ looked worried now, “Hold it a minute, are you saying we won’t be able to do Agile at all?

“In a sense I am,” said Colin nodding seriously, “Agile is a binary thing; either you are, or you aren’t. Having said that, the intent of Agile is to uncover better ways of doing software, so why don’t we start by looking at the things we can improve by bringing in some Agile practices?”

RJ sighed with relief, “So we will be able to do some Agile then?”

Colin agreed with him, “You can do some Agile practices and you can use some Agile techniques. You won’t be Agile you’ll be what we call ‘AgileBut’ In other words; you’ll be doing what you can to be Agile but you won’t be upholding all of the principles. For example, you don’t have a co-located team.”

“I should also tell you that responsibility without authority is one of the most common recipes for stress. You have the responsibility for making your projects Agile but you don’t have the authority to make your team uphold the Agile principles. It’s a no-win situation for you and you might want to have a conversation with your boss about that.”

“I’ll do that,” said RJ, “Thanks very much for your help today, it’s really put things into perspective for me.”

Colin left, wondering how many HR complaints this current trend of issuing Agile mandates might bring.

Sunday, 13 October 2013

doggie calculus

Richard Jones was CTO for a large retail company that relied heavily on e-commerce for most of its turnover. Aged 45, he’d been a software developer once and had risen through the ranks before reaching his current position. The responsibility of his position lay heavy on him but he took pride in the ability of his team and worried deeply when they weren’t performing.

This was one of those days. Development speed had slowed to a crawl and the defect rate was through the roof. Every time they fixed one defect, they created at least two more. He’d talked to the team and he knew they were doing everything they could but it just wasn’t working.

Richard knew they weren’t going to make their delivery date but he also knew he couldn’t talk to the board without a plan of action. A year or so ago, he’d engaged a coach to help the team improve their processes, which had a tremendous effect on the team’s performance and predictability. Was it time to and get the coach back?

Fast-forward a couple of weeks and the pair of them were enjoying a coffee outside the local Starbucks. Colin, the coach, had just told Richard the results of the static analysis he’d done on the team’s code.

“But my developers are brilliant, there isn’t anything they don’t know about Java, Web Services, AJAX… you name it, you won’t find anyone that knows more about it than this team” said Richard emphatically. “Everybody praises them for their solutions, we’ve won awards for the website and the customers absolutely love it.” He took a sip from his cup, “How can you sit there and tell me our system is poorly designed.”

“Ok,” said Colin looking him straight in the eye, “Let me tell you about my dog, Russell. Russell is good at catching balls. He always seems to be able to predict where the ball will land and get there first so he can catch it.”

“What’s that got to do with my team?” asked Richard.

Colin continued, “Does this mean Russell uses calculus to predict where the ball will land? I don’t think so. I think he gets feedback from his surroundings and adjust his position relative to the ball. When it’s close enough, he grabs it with his mouth. He doesn’t understand the underlying principles of ballistics at all.”

“I still don’t get it,” said Richard, looking puzzled.

“In a sense, your team is like my dog. They have excellent technical skills and they have excellent external design skills. They use those skills to deliver good-looking solutions and you reward them for it.” He leaned forward to make his next point, “However, the static analysis of the code tells us they have less understanding of the underlying principles of object-oriented design.”

Leaning back in his chair he continued, “The internal design of the code is poor and you’ve built up what we call a technical debt. This is what’s making it so difficult for them to deliver software. Your system is fragile – every time you try to make a change, you break something.”

“I see what you’re saying and I guess the analysis can’t lie, so how do we fix this?” Richard asked.

“We can train and coach your team, in design principles” replied Colin. “We can also teach them how to identify what we call smells in code and refactor them to improve the designs.”

“So some training for the team and everything will be fixed. I imagine we’ll need to spend some time reducing the technical debt, too?” said Richard, looking round for the waiter so he could pay the bill.

“The training is just the start,” said Colin as they walked back to the office. “You also need to start paying attention to internal design. Previously, you put emphasis on the external design and as a result, your team is good at it. Pay the same attention to the internal design and your team will become good at that too. Making static analysis part of the check-in process and doing team code-reviews are simple ways you can start to make the internal design more visible.”

They’re still working on it but Richard’s team are in a much better place now. The training gave them a new awareness of good design principles and prompted discussion amongst them. Implementing static analysis on check-in has forced them to pay continuous attention to the internal design of their systems.

Saturday, 13 October 2012

the field of dreams

It was 2005, some years after the dotcom boom and a financial software house asked Colin to help with a project they just couldn’t seem to deliver.

Colin sat down at the table with the development team and Henry, the Marketing Director. “Ok,” he said, “You’ve been working on this project for three years but haven’t released any software. Can anyone tell me what the problem is?”

Henry spoke up first, “We’ve told them many times what we need but they keep building something totally different.”

Mike, the development team lead, shook his head and said, “Yes, but you keep asking for things that can’t be built!”

After some similar exchanges, the conversation looked like descending into total chaos so Colin held up his hand to get everybody’s attention. “Can you give me an example?” he asked.

“You have to understand we are working in regulated environments,” said Henry, staring angrily at Mike, “this means it’s a massive advantage to us if we can supply a footprint-free application. Anything that needs installing can take months before approval from the customer’s IT department. If we had a web-based product, we could avoid all of that completely. I’ve spoken to so many of our customers and they’ve all said it’s such a great idea. I guarantee we’ll sell thirty thousand licenses in the first month after release”

“We’ve heard all this before!” said Mike with a sigh. ”I keep telling you; it only needs a small download so we can run it as an ActiveX control.”

“You just don’t get it!” said Henry, “What part of footprint-free don’t you understand? Even one single byte has to be approved before it can be installed.”

Colin held up his hand again, “Why do we need an ActiveX control?”

“This is a charting application,” explained Mike, “ActiveX gives us the ability to draw charts and append lines and text to them. These are all features that Mike says are necessary.” “

“What about alternative technologies?” asked Colin, “how about Vector Markup Language? That doesn’t need a download.”

“True, but VML only works in Internet Explorer and we need to support as many browsers as we possibly can,” explained Mike. “Browser compatibility is a big concern for us.”

Ollie, the Operations Manager spoke up, “According to our web stats, ninety-eight percent of the users use Internet Explorer 5.5 and above, so nearly all our clients can use VML”

“If anyone complains, I’ll personally buy them a PC with Internet Explorer installed,” said Henry smiling.

Eventually, the development team agreed to build the project using VML, even though they considered it a legacy technology. As part of the plan for the first release, Colin insisted that Mike, Henry and the CEO met weekly for a ‘show-and-tell’ meeting so they could agree the project was progressing the way they wanted.

All went well and at the end of the scheduled three months, they released the application. “It’s up to you now, Henry,” said Willy, the CEO, at the project launch party. “Mike and his boys have built you exactly what you asked for, now get out there and collect all those license fees you’ve got lined up.”

Three months later Colin sat in on another meeting with the board. “I’m not sure what to say,” said Willy, “Over three years we’ve worked on that project and we’ve sold only two licences. We can’t blame the team, they built exactly what we asked them to and we reviewed the progress every week. What on earth happened, Henry?”

“I’m sorry Willy but I thought if we built it, they would come. Like in ‘Field of Dreams,’ the Kevin Costner film.” said Henry, “All our customers said it was a great idea so I assumed they would buy it but when it came to signing contracts, they seemed to change their minds.”

Willy stood up, “The only consolation is that we now know to stop working on it and concentrate on other projects.”

Colin looked up at him, “This is called failing fast. Early feedback lets us verify our assumptions so we can discard hypotheses that don’t work and concentrate on proven ones. It took us just three months to do that. You spent three years arguing about conflicting assumptions without putting any of them to the test.”

Willy put his head in his hands;” I don’t even want to think how much money we’d have saved if we’d done this three years ago.”

the point

Willy, the CEO, was at his desk feeling very satisfied and confident as he read the monthly IT report. Everything was looking good, the report told him the development teams were really performing well and velocity was up yet again. Unfortunately, an email from Jackie, the CFO, disturbed his calm.

“I can see the IT teams are busy,” read the email, “but busy doing what? Can we get our changes delivered? They will save us hours of work every month. Why haven’t they been delivered? – Jackie.”

To see if he could resolve Jackie’s issues, Willy hosted a meeting between her and RJ, the CTO.

“Right, what’s the issue, Jackie?” asked RJ, keen to get the meeting started.

“RJ, every month I get reports telling me how many more points your teams have delivered.” Said Jackie, visibly frustrated. “In the latest one, you’re bragging about some of the teams delivering sixty points a sprint for the last three sprints. They may have delivered 180 points but I’ve seen none of my changes. Where’s my stuff?”

After some discussion between them, Willy decides the only way to resolve the situation is to get help from Colin, the Value Driven Software consultant.

Looking at the Sprint Reports, Colin sees that everything is measured in points and notes the third-party suppliers have increased their delivery quota by twenty percent.

“We pay our outsourcing partners on points delivered.” Explained RJ, “If they exceed their quotas, we reward them and if they don’t, we fine them. Using velocity to measure their performance is a good way of motivating them to deliver and we have systems in place to guarantee the quality of their work. You can see it’s working, as the velocity is improving.”

“What’s actually happening here is called point inflation,” said Colin, looking at them seriously. “Story points are not a measure of performance; they are simply used to predict how much work we can do in future. For example, if I did five crossword puzzles a day, I would have a velocity of five points per day and you might expect me to solve five every day. However, some crosswords are more difficult than others are and might be worth two points, others easier and only worth half a point. As long as there a relative weighting, you would still expect me to solve around five point’s worth of puzzles per day.”

Colin looked up to see if they were still paying attention, “Now it turns out, the only person who knows how difficult the puzzles are is me but you don’t care about that because you only care about them being solved. I can use my knowledge to tell you how difficult each one is and because you know how many there are, you can use that to predict when they will all be finished, just like a project. Do you follow?”

"Yes,” said RJ, “but isn’t that exactly what we’ve been doing?

“Not quite,” said Colin. “This all depends on my definition of ‘difficult’ staying the same and as long as nothing influences it, it probably will. However, if you were to offer me £1 for every point I complete and then ask me how many points each puzzle is worth, that probably will influence my rating. It may well cause me to say that what was previously one point was now two points and you would never know because I’m the only one who really knows how difficult they are.”

“Isn’t that a bit dishonest?” asked RJ.

“We call it gaming but it’s purely business,” said Colin, laughing. “What would you do if someone offered you a contract offering a pound per point and allowing you to define a point? Are you blaming them for your own folly?”

“Now you put it like that, it does sound like I’ve been a bit daft,” said RJ, ruefully. “Fortunately, we only sign-off three months at a time, so I can change the contract soon. I am so glad we had the sense not to sign up for more than that. I might have lost my job over this”

Colin smiled at him, “Consider yourself lucky you can get out of it, you won’t believe some of the contracts I’ve seen organisations tied into, three years is not unusual.”

Joining in the conversation, Janet said, “At least we’ve learned that velocity shouldn’t be used to measure performance and definitely should not be used to reward. I’m sure we’ll be much more careful about our contracts in future, too.”


Friday, 11 March 2011

not what i meant (part two)

Currently, I'm staying in Bangalore and, as many of you may know, I like to keep myself presentable, so everyday I clean my shoes using the little tin of polish provided free by the hotel.

Yesterday however, the housekeeping staff apparently didn't notice I'd used it and so didn't replace it, as they usually do when they make up the room. Now I could have gone, or called, down to the front desk to have them send me some up but it isn't really a big deal and it won't hurt my shoes to have them miss a day's polishing, so I just left a note on the bed this morning saying, "Shoe polish please."

Imagine my surpise when I returned from work today to find there was still no sign of any shoe polish in the room but there was a very highly polished pair of trainers sitting where my grungy old gymn shoes had been this morning!

Written requirements, eh?

How can they not work? :)

the business value of telemetry

Dynamic technologies and infrastructure allow server failures and network issues to be quickly addressed, easily mitigated and, in many cas...