MIET

I'm now officially a Member of the Institution of Engineering and Technology (IET) after an application process with rather a lot of unexpected to-ing and fro-ing from communications between my sponsor and the IET getting lost. So, I now have another group of letters to put after my name.

The biggest difference between the British Computer Society (BCS) and the IET is in their publications. The IET website and members journal (E&T) are a lot more engaging than the BCS website and its members journal (ITNow) - though ITNow has featured some passionate engagement recently (but I'm still waiting for my copy to arrive). E&T features engaging articles that go into depth, whilst ITNow articles often appear to be lightweight puffs for products and services by their authors. Also, at around 70,000 members, the BCS can only manage to produce a journal with a handfull of pages, whilst the IET with 150,000 members produces a monthly journal with much more than twice as many pages.

Whilst at university I had the choice between the BCS and the Institution of Electrical Engineers (IEE) (who would later merge to form the IET). At that time I considered myself very much to be a computer scientist, not an electrical engineer.

After graduating (a few times) I saw no value in being a BCS member so I resigned.

After a few years I began to see myself as a software engineer, and that what I was doing was engineering. Since the BCS was a member of the Engineering Council I rejoined the BCS and eventually attained Chartered Engineer status. Unfortunately, I see less and less evidence of engineering in the BCS, whilst the IET certainly maintains its engineering face.

Wise Customer went to the house of Proud Businessman

Wise Customer greeted Proud Businessman, "Greetings Proud Businessman, I wish to purchase a service from you, but I must first ask a question."

Proud Businessman replied, "Greetings Wise Customer, my heart is gladdened that you wish to purchase a service. But do tell me what question troubles you"

Wise Customer asked, "Proud Businessman, with your service I hope to increase the quantity of gold flowing into my chest, but the cost of your service will take a great deal of gold from my chest. How do I know that the service you provide will be good?"

Proud Businessman opened the door to a storage room and bade Wise Customer to enter. Proud Businessman pointed to a stack of parchment at the back of the room bearing the legend ISO 9001 and said, "Behold Wise Customer, do not be afraid of the quality of my service, for we have a quality process."

Wise Customer brushed a cobweb from his eyes and said, "Proud Businessman my eyes clearly see that there is much dust gathered on these parchments. How can that be so?"

"The lines on my face and the greyness of my hair show you my age, just as the thickness of the dust shows that I have had a quality process for many years." replied Proud Businessman

Wise Customer thanked Proud Businessman saying that he must visit his apothecary for he had developed an irritation from the dust and must seek an ointment to provide relief.

Proud Businessman was happy for he had just received a wealthy government contract that morning.

Agile Success

I'm always interested in project success, so I was drawn to this article in CIO.com: "5 Principles for Reducing IT Project Failure"

Rather than being IT-specific I would say that these are simply 5 principles for reducing project failure:

1. Communicate: If everyone involved in your IT project doesn’t know what they’re working on, when it’s due, how to get it done and who the audience is, how can you possibly expect your project to succeed?

The aim is to ensure that everyone in the project knows what is going on, what is expected, when it's expected, for whom it's expected, etc. Nobody is then treated like a mushroom kept in the dark and fed fertiliser.

2. Consolidate: We’re talking about information and tasks here.

If you can't find the right information for what you're working on, or it takes you a long time to find it, you are wasting time and effort that can be better spent working constructively towards your project goals. Reduce bureaucracy, cut through the red tape and put information within easy reach so everyone can do the job that they are supposed to be doing.

3. Prioritize: Issues come in, bugs are discovered, and new application features are conceived of every day.

Dropping everything to work on a just-reported bug, or to do a "quick job" for someone is probably not the best use of someone's time. The bug may be of lower priority than what you are currently working on. The "quick job" is a distraction where your time can be better spent working on something delivering higher value.

4. Requirements: In ALM and your SDLC, before you can do anything else, you need to identify, prioritize and agree on application (and project) requirements.

It is fundamental that you need to know what the requirements are before you work on something. Once requirements are elicited, they can be analysed and prioritised. Misunderstandings can be removed to ensure that the project team and stakeholders are of one view as to what the requirements are. Understood requirements mean that something can be designed and built. Understood requirements mean that a plan can be made to test them.

5. Manage Time: As management, it’s up to you to take the first step in setting reasonable deadlines and milestones for your team throughout the project.

Knowing where you are in a project, where you should be and how fast you are delivering are vital pieces of information in determining what will be delivered by when.

Alternatively, these are just, 5 Agile/Scrum principles.


1. Communicate

Scrum revolves around a cross-functional, self-organising Scrum Team that has a daily stand-up meeting where every team member communicates what he did the previous day, what he is committing to do today and if he has any blockages or impediments.

Developers, testers, DBAs, designers, BAs are all kept informed of what all the other members of the Scrum Team are doing.

Scrum also involves the whole Scrum Team being involved in the Sprint Planning.

The Scrum Board and Burndown Chart should be visible to all, so everybody can see what the Scrum Team is working on, and what their progress is - instant reporting!

2. Consolidate

Agility is about individuals and interactions being valued more than processes and tools, and about working code being valued more than comprehensive documentation. "Muda", one of the Toyota Principles, is focused on removing waste, where waste means wasted materials but also means wasted time and effort.

Agile practices refer to doing "just enough" or doing what is "sufficient and necessary". Agile teams commonly use wikis to document information, they record requirements on cards or Post It notes which are kept on the Scrum Board (or Kanban Board).

3. Prioritise

Scrum requires the Product Owner to prioritise work. The Scrum Team only works on what is currently the highest priority collection of requirements. Requirements should be prioritised so that the ones delivering the highest business value are delivered first. Also, those requirements which eliminate the most risk should also be prioritised highest.

Considering simply high and low business value and risk, the best order in which to prioritise requirements according to their business value and risk is:

1. High risk, High business value
2. Low risk, High business value
3. Low risk, Low business value
4. High risk, Low business value

The aim is to eliminate as much risk and deliver as much business value as early as possible, overall delivering a high ROI. Risk can also be categorised as uncertainty - the uncertainty that something is feasible.

Bugs, new requirements, existing requirements all go on the backlog and are prioritised accordingly.


4. Requirements

Scrum can not proceed without requirements.

The list of requirements is maintained in a Product Backlog, in priority order (c.f. Prioritise)


5. Manage Time

Scrum sets regular deadlines for the Scrum Team to commit itself to delivering working software satisfying the requirements.

Progress is visible on the Scrum Board - which presents a snapshot of progress in terms of what's Done, what the team are Doing and what's still To Do. Progress is also visible in the Burndown Chart which shows the rate of progress.

Requirements and tasks are estimated by the people who will do the work - acknowledged to be more accurate than estimates by people who do not do the work - and that knowledge is used to set realistic expectations.

Daily reporting in the Daily Scrum means that people are held accountable to the whole Scrum Team for the commitments they make each day.


So, 5 principles for reducing IT project failure are satisfied by Agile practices. Though I often remark that what are often regarded as Agile practices (coding standards, continuous integration, etc.) are just good engineering practices. So, Alistair Cockburn is right that Agile is the norm - it's just good practice.

Software Development is not a Production Line

I was discussing the software development process with one of the architects in my team this afternoon. The key observation was that software development is not a production line; the only production line in software development is when you're stamping out the media once the software has been developed.

Software development, by the very nature of software, suffers from maleability. Because it is relatively easy to change software, change ensues.

Walter Vincenti in "What Engineers know and how they know it" coined the terms "normal design" and "radical design".

Normal design is when "...the engineer knows at the outset how the device works, customary features, and if you design it properly along such lines, good likelihood of accomplishing the desired task".

Radical design is where you are doing something new and innovative and you don’t know how it should be arranged, you don’t know how it works, you’ve never really seen anything quite like this before and you have no presumption of success.

Microprocessor Development

Microprocessor development is comparable to software development: there is lots of design work and experimentation, then the resulting microprocessor is stamped out on a production line.

The environments in which microprocessors find themselves deployed are a lot more controlled than software, the microprocessor's interface to the circuit board on which it is mounted is well defined, the strength, potential, frequency and shape of the signals the microprocessor receives is fairly well defined.

Software, particularly when used by humans (or other software created by humans), deals with a vastly more complex environment.

Craftsmen

Rather than production line workers the people involved in producing software are like a collection of craftsmen.

Like a craftsman, whenever working on a problem, each one will:

• analyse the problem to some degree
  (the stone sculptor will observe and feel the stone)
• design a solution, or a sufficient first step
  (the stone sculptor will decide where the first major cuts will be)
• implement a solution
  (the stone sculptor will start hammering and chiseling at the stone based on his design)
• test the solution
  (the sculptor will look at the carved stone to decide whether it matches the subject)

The State of Agile in 2009

VersionOne have released their fourth annual State of Agile Development Survey results for 2009

I still find it odd that people regard things like coding standards, refactoring and unit testing, as agile techniques; even continuous integration and automated builds. These techniques are just good software engineering practice and should be used everywhere, irrespective of whether you are trying to be agile or not.

Lack of experience with agile methods was the largest reported cause of failed agile projects. Though it's not clear whether the report means failed projects that were supposed to be agile or projects where the agility failed.

Would you Employ only a Certified Software Engineer?

I posted the following in a group on LinkedIn after a question in the group asking what the focus of the BCS should be in 2010:

Would you employ an amateur, DIY bricklayer to build your wall?
Would you employ someone who's read a couple of accountancy books to be your accountant?

Chances are you answer is "no".

Would you employ an amateur hobbyist coder?

Chances are, the answer is "yes".

Would you build a brick wall for yourself, or would you help do the books for your club?

Chances are, the answer is "yes"

Computer programming (and that's my background) is an area where everybody feels that they can do a bit of DIY bricklaying - especially with some scripts and a spreadsheet which then becomes a business-critical application.

Professional accreditation is all well and good, but there is no difference (from employers' perspectives) between a hobbyist coder and a CITP-holder.

Other professions (law, accountancy, medicine) require their professionals to have some professional training as well as their basic qualifications. It's also difficult to be an un-registered lawyer, accountant, doctor, etc. So there is a consequence for not being professionally recognised.

Maybe we need a new CSE for the 21st century, a Certified Software Engineer. The holder of such a certification would have to demonstrate good software engineering skills: requirements elicitation, requirements modelling, solution design, coding standards, testing, source control, documentation, maintenance, etc.

Experience Counts for Less?

The Wall Street Journal article "Dangers of Clinging to Solutions of the Past" illustrates the value of challenging assumptions and the inspect-and-adapt cycle. Whilst the article boldly asserts that increased experience leads to increased project failures, this is attributed to an increased confidence on behalf of the project managers concerned.

I would like to add that it is of little use to know that a practice worked previously without knowing why it actually worked, and conversely one should also know why something did not work in a particular situation. By knowing the "why" one is able to apply the experience to the appropriate situation.

We can only discover the reasons by taking the time to ask ourselves what those reasons are. Scrum's retrospective meeting (a post-iteration review) generally poses 3 questions:

• What went well?
• What went wrong?
• What to do better, and how?

I would now say that the 3 questions should be posed as:

• What went well, and why?
• What went wrong, and why?
• What to do better, and how?

Peopleware: you must read this book!

Many people have heard the quote that the best software developers are 10 times more productive than the worst. Whilst I was reading the course material for my course in project management I came across the source for this statistic:

"Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister, 2nd edition, Dorset House, 1999

Reading this book you get to see the rest of the results:

• the best developers are 2.5 times more productive than the average - so there are a lot of very unproductive developers out there
• the best developers are in development teams that are 10 times more productive than the worst teams - it's not just about individuals, but who they work with, who they work for and in what kind of environment they work
• people are more productive when they have fewer distractions - obvious, but lost on many managers
• Parkinson's Law was a joke about a bureaucracy, not a general observation
• higher pressure does not improve productivity and/or quality

After just reading a couple of pages I came to the conclusion that this book should be made a mandatory read before anyone takes on a new position as a manager - including, or especially, several of my previous managers!

I've only read a few chapters, but my enthusiam shows no bounds.

Nam et ipsa scientia potestas est

At a reception for us fresh-faced (well, maybe more like spotty-faced) computer science freshers in 1987 I was asked by a fellow student what I thought the best computer was. My answer was, "Orac from Blake's 7"

Thinking back it may not have been such a facetious answer.

Orac was powerful because it networked with other computers, not just sitting there on its own like the traditional super-computer of science fiction (and super-computers 30 years ago). Orac had the ability to communicate with all other computers that carry tarriel cells - the basic component of all computer systems in the Blake's 7 future, designed by Ensor (Orac's creator) at a young age.

Able to mine any data on any computer system it had a vast wealth of raw data at its disposal that it could process into useful information. Thirty years on from the creation of Blake's 7 we are beginning to see the wealth of information that can be provided by the Internet and the beginnings of practical distributed computing in the form of cloud computing.

As Sun Microsystems says: the network is the computer

Officially an Engineer

With all the paperwork completed, I am now officially a Chartered Engineer.

So the letters CEng now get added after my name, which means my CV gets updated again, just like when I acquired the post-nominals CITP.

This doesn't mean that I can now go around saying that I can build roads and bridges - in fact it means that one of my professional duties is to not say that I can do things which I am not qualified to do. What it does mean is that I am recognised by my peers as a professional engineer who applies engineering discipline to the practice of software engineering.

Degrees of Experience

I chose my undergraduate degree course because it was ranked the number 1 computing course by British employers. After all these years, does what I was taught in that course serve me today?

I studied Computer Science, not Software Engineering. My work in industry has very little science about it, and more to do with engineering and project management.

I was not taught how to write "good" code, only correct code that satisfies functional requirements.

Similarly, I was not taught the benefits of database de-normalisation in a practical environment.

This is the craft vs science paradox. I was taught the science of computing, but the real-world day-to-day application was missing.

OK, I might be a bit harsh in saying the real-world application was missing. After all, I got by writing poorly engineered code for a long time, and so have many others, and even more still do. Also, this was 20 years ago, and things may have changed in the last 2 decades.

Aspect Oriented Programming (AOP) was unheard of.

Design patterns were still to be popularised by the gang of four.

The web was still to be invented, though the Internet was around with plenty of e-mail, usenet and FTP activity.

It is reasuring to read that Bjarne Stroustrup (he of C++ fame) teaches at Texas A&M University's Department of Computer Science a course on Advanced Programming Techniques which addresses the issue of:

writing code to be used and maintained by others than its implementers

which also includes a group project, hence requiring student programmers to collaborate as a team.

Though today I find that the two biggest skills sought by employers (at least for enterprise software) are:
understanding of an Integrated Development Environment (IDE) e.g. Visual Studio in whatever version;
familiarity with framework code libraries such as .NET

The days of the hero coder with his specialised weapons of only a simple editor and his knowledge of algorithms are long gone. There are common tools now and infantry coders rely on an industry of standard munitions.

Now a Professional

I'm now a Chartered IT Professional, so I can now add the letters CITP after my name.

Despite this latest award I've not quite achieved my ambition of having more letters after my name than in my name. But if I include the spaces then I have equalled the length of my name.

Upon receiving the news I thought, "Great! How do I update my CV now?"

OK, so I put CITP after my name, but I now need a new section for awards as it does not really sit well in the Certification section, which is more geared towards course-based material. After all, that's the whole point of acquiring these qualifications, isn't it?

The BCS says that as a Chartered IT Professional you should gain more credibility with employers and a competitive edge over your peers, helping you to advance your career more effectively. BCS campaigns with employers to recognise CITP status as the benchmark for highly skilled and committed IT professionals.

Whilst that is a noble goal, I fail to see it happening at the moment. On the one hand, not many organisations will have heard of the British Computer Society. On the other hand, of those that have heard of the BCS, only a few will have heard of Chartered IT Professionals.

So why did I seek out this extra award?

Well, I believe that professionalism in IT is all too often lacking, and that we need to put the "engineering" into Software Engineering.

If Civil Engineering was like Software Engineering we would have bridges built late, over budget and not meeting the customer requirements. They would also collapse frequently, need upgrading regularly, and would often be closed for servicing. And that is just for the few that would actually get built.

Would you hire an unqualified lawyer? Doctor? Accountant?

Then why do people hire self-made/amateur IT staff with no professional qualifications?

Would you hire a bricklayer who's only building experience is some DIY at home? Then why hire IT staff whose only experience is a bit of scripting and coding at home? (Having done plenty of DIY bricklaying myself, which I find quite satisfying, I would still rather hire a professional bricklayer for anything but the most basic job.)

For the last few years I have been very much quality focused, pushing for the adoption of:

• coding standards
• SQL standards
• design patterns
• test-driven development
• continuous integration
• peer-review
• well-defined processes

The sad thing is that in each team I work with I have to establish these (what seem to me) basic practices.

Each team I've worked in I've said that anyone other than a tester is an amateur tester, and all too often I have not had professional testers to draw on.

Or maybe I'm thinking about this the wrong way, and that it's really a matter of Gentlemen and Players? Whilst the notion of the gentleman athlete is romantic, it is exceedingly out-dated, and has long been surpassed by the professional player.

Lack of Ownership

To break the old way of thinking I kept hammering home the message with my team that:
"You do not own the product/requirements"

Unfortunately, this became interpreted as:
"You have no responsibility or stake"

By breaking down the old way of thinking, I had not replaced it with something else.

The team felt that they were just randomly picking tasks from the scrum board each morning.

(A clue should have been the fact that it was taking so long at each daily scrum for people to choose their tasks. This showed that people were un-prepared for deciding what they would do that day.)