Most software groups (and I'm sure that this doesn't apply to just software groups) with any sort of history have a record of trying out prescribed process improvement after process improvement, many of them ending in some sort of failure - generally meaning that the process didn't meet the expectation or goals it was introduced with.
This can be especially true of process improvements that are built around an expensive software tool. I've had my fair share of colleagues lost to some sales type or evangelist touting the latest and greatest in software silver bullets. The use of the word 'evangelist' is telling, and conjures up images of an overzealous individual pushing unfounded ideas at you - it gives an indication of the mysic aura that a 'process guru' can give themselves by which one can be blinded.
CASE tools aren't that useful when they constrain you too much to one process, and some companies that push tools as well as processes rely on a self-created cult-like following whipped up from the guru of the day's scribblings. When these words of wisdom are unfounded, unproven and (even better) not understandable, they can be taken by savvy marketers to sell the tool.
A prescribed process (from a heavy one to a very light or 'agile' one) may fit perfectly into the company, work environment, or culture it grew up in but moving it into another environment, more often than not, can transform it into a useless or even dangerous beast.
In the translation, you can lose the meaning of important concepts, miss out on understanding vital assumptions and all the other pitfalls associated with one person attempting to describe a complex system to another. No matter how many reams of written documents or concise manifestos one writes, some things just get missed - even when the two communicator's work cultures are very similar.
What would be much more useful and less prone to failure is an expert in processes to mentor a group over a period of time (even indefinitely), who can prescribe and tailor a process to meet their current needs, to put in place mechanisms to measure the success and progress of the group and ultimately advance the group's software capability - a process specialist or change agent.
A software CASE tool is no substitute for an experienced mentor!
Saturday, 13 September 2008
Saturday, 23 August 2008
Ethical policies of professional IT bodies
I consider myself a professional software engineer. To be recognised as such in the wider community involves, amongst other things, subscribing to a professional ethical policy. Personally, I feel an ethical policy must involve not working on anything that will result in harm or even death to others (i.e. no 'defence' work). So which professional IT bodies would be suitable for me to join, with this in mind?
The BCS - avoids the issue by not defining an ethical policy - only has a code of conduct which
This is a bit of a cop-out, and avoids the difficult questions altogether.
The IEEE - does have a code of ethics - which does, on first glance seem to fit the bill:
But I'm also aware that the IEEE has many high profile members who work in the defence industry and also produces specifications created and used in the defence industry.
The ACM - Much better, uses the term 'human rights', and takes the most care of these three bodies to make clear their ethical stance and to give direction:
I'm still undecided - I believe I need to spend a lot more time researching this topic, as the standard policy for most IT organisations appear to allow members working in defence - even if it's only discernible by reading between the lines.
The BCS - avoids the issue by not defining an ethical policy - only has a code of conduct which
'... governs your personal conduct as an individual member of the BCS and not the nature of business or ethics of the relevant authority'.
This is a bit of a cop-out, and avoids the difficult questions altogether.
The IEEE - does have a code of ethics - which does, on first glance seem to fit the bill:
1. to accept responsibility in making decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;
....
9. to avoid injuring others, their property, reputation, or employment by false or malicious action;
But I'm also aware that the IEEE has many high profile members who work in the defence industry and also produces specifications created and used in the defence industry.
The ACM - Much better, uses the term 'human rights', and takes the most care of these three bodies to make clear their ethical stance and to give direction:
This principle concerning the quality of life of all people affirms an obligation to protect fundamental human rights and to respect the diversity of all cultures. An essential aim of computing professionals is to minimize negative consequences of computing systems, including threats to health and safety. When designing or implementing systems, computing professionals must attempt to ensure that the products of their efforts will be used in socially responsible ways, will meet social needs, and will avoid harmful effects to health and welfare.
In addition to a safe social environment, human well-being includes a safe natural environment. Therefore, computing professionals who design and develop systems must be alert to, and make others aware of, any potential damage to the local or global environment.There's also an interesting discussion of ethics in this paper here, and a very thorough discussion of ICT bodies and ethics, with recommendations here.
I'm still undecided - I believe I need to spend a lot more time researching this topic, as the standard policy for most IT organisations appear to allow members working in defence - even if it's only discernible by reading between the lines.
Tuesday, 29 July 2008
A Linux Literary Trilogy
When I started delving into the world of Linux development, I was not only befuddled by the strange code layout and conventions, I also found the culture and ethos of Linux very confusing. There were three books that were invaluable in pulling my understanding out of this quagmire, which I'll mention briefly:
The Linux Programmer's Toolbox by John Fusco. Allows your Linux usefulness to go from 0-60 in six seconds. Not totally exhaustive on all tools Linux, but it's brilliant for giving you an up to date map of the Linux development environment. Not only that, but it can give you a greater understanding of any development environment which uses make or GCC. I really can't recommend this book highly enough - it's so well written and laid out that I use it regularly as a reference manual. Not only does it cover many of the useful Linux tools (and shows you how to look for the rest), it covers how the kernel works, gnu make systems, debugging and has a nice comprehensive guide to using Vim and Emacs effectively (although, sadly, it doesn't say which is best - but I think you know the answer to that).
The Art of Unix Programming by Eric S. Raymond (Link is to the full book text). Once you have all the tools, you'll want to know how to use them. Not only does this book give you the why behind the what of Linux - explaining the design and implementation mechanisms that have shaped it, it gives an excellent narrative on the history and context in which these mechanisms evolved from someone who was there at the time. Make sure you absorb his 17 basics of the Unix philosophy, don't trust yourself to touch a line of code until you do! I'll repeat them here, just in case you miss them:
The Art of Happiness: A Handbook for Living, by the Dalai Lama. Not a technology book, but it has to be said some of the greatest challenges I've had in my working environment is not the code or the technology, but the people.
This book gives a good grounding in principles giving you a greater knowledge of oneself and others - based around the idea that compassion for others is the main source of happiness.
Useful for those times when you need to take a deep breath and stand back....
The Linux Programmer's Toolbox by John Fusco. Allows your Linux usefulness to go from 0-60 in six seconds. Not totally exhaustive on all tools Linux, but it's brilliant for giving you an up to date map of the Linux development environment. Not only that, but it can give you a greater understanding of any development environment which uses make or GCC. I really can't recommend this book highly enough - it's so well written and laid out that I use it regularly as a reference manual. Not only does it cover many of the useful Linux tools (and shows you how to look for the rest), it covers how the kernel works, gnu make systems, debugging and has a nice comprehensive guide to using Vim and Emacs effectively (although, sadly, it doesn't say which is best - but I think you know the answer to that).
The Art of Unix Programming by Eric S. Raymond (Link is to the full book text). Once you have all the tools, you'll want to know how to use them. Not only does this book give you the why behind the what of Linux - explaining the design and implementation mechanisms that have shaped it, it gives an excellent narrative on the history and context in which these mechanisms evolved from someone who was there at the time. Make sure you absorb his 17 basics of the Unix philosophy, don't trust yourself to touch a line of code until you do! I'll repeat them here, just in case you miss them:
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.
The Art of Happiness: A Handbook for Living, by the Dalai Lama. Not a technology book, but it has to be said some of the greatest challenges I've had in my working environment is not the code or the technology, but the people.
This book gives a good grounding in principles giving you a greater knowledge of oneself and others - based around the idea that compassion for others is the main source of happiness.
Useful for those times when you need to take a deep breath and stand back....
Thursday, 12 June 2008
Using the correct case
I think use cases are great, but unfortunately the term 'Use Case' has one meaning if you use them as a working tool, and more often than not, another meaning if used as a buzz-word in conversation.
It's a commonly used term by developers, but personally, I often cringe when someone in a management or marketing role uses it to identify a product feature or even just a single scenario - a clear case of use case misuse!
Use cases are a bit more technical than just an idea of how something may be used - the term was first coined by Iva in the 80's, and has since been expanded on greatly by the likes of Alistair Cockburn and his peers. They are a brilliant tool for gathering requirements and consist of nothing more than simple text descriptions.
However, even though a finished use case should be a shining beacon of simplicity and clarity, getting to that point can be devilishly complex and requires more than a little experience in writing use cases - the heuristic 'practice makes perfect' certainly holds true here. The trouble is, once you begin utilising use cases it quickly becomes apparent how useful they are in many more areas of software development than just requirements gathering.
A short list of areas where use cases can add value :
I won't go into more detail here, as plenty of insightful information is available elsewhere on these topics (See Alistair Cockburn's work, for example). Suffice to say that you can drive almost the whole software process using a use-case centric approach - not that you should, of course, and the circumstances to which you are fitting a process must always be considered carefully.
Once you realise the power of well-written use cases and understand the areas in which you will use them, it seems a good idea to spend more time considering their details and form - unfortunately there is no one-shoe-fits-all approach to this as the structure of a use case is very dependent on the domain and environment in which it is being used.
One example of this is for use cases geared towards embedded systems, where I have found the assumption of everything happening in 'zero time' to be very useful - you end a use case scenario whenever you have to wait for something. This approach would be unwieldy when writing a set of high-level use cases for a user interface, on the other hand.
One can spend many hours getting a relatively small use case or set of use cases together into a usable form that may appear to be a pedantic waste of time, but to an experienced use case author is time well spent. Many lessons are learnt and dead-ends reached when going through the process of writing and using use cases 'in anger', that time spent early on considering these lessons proves very beneficial in the long run.
It's a commonly used term by developers, but personally, I often cringe when someone in a management or marketing role uses it to identify a product feature or even just a single scenario - a clear case of use case misuse!
Use cases are a bit more technical than just an idea of how something may be used - the term was first coined by Iva in the 80's, and has since been expanded on greatly by the likes of Alistair Cockburn and his peers. They are a brilliant tool for gathering requirements and consist of nothing more than simple text descriptions.
However, even though a finished use case should be a shining beacon of simplicity and clarity, getting to that point can be devilishly complex and requires more than a little experience in writing use cases - the heuristic 'practice makes perfect' certainly holds true here. The trouble is, once you begin utilising use cases it quickly becomes apparent how useful they are in many more areas of software development than just requirements gathering.
A short list of areas where use cases can add value :
- Requirements analysis - Is the use case describing what you want the system to do?
- Requirement traceability - Justifying the inclusion of a particular piece of design or code.
- Software design - Use cases can lead straight into the design phase, e.g. by using sequence diagrams for each important use case thread.
- Planning and tracking - A set of use cases breaks the software system down into more manageable chunks, which can be planned and progress measured against.
- Test design and writing - A use case is also a ready-made test case.
- Release management - When deciding which features to include or wait for inclusion, use cases provide a mechanism for linking features to user goals.
- Change management - Especially for iterative development, use cases can, for example, aid by scoping change requests to work estimates.
I won't go into more detail here, as plenty of insightful information is available elsewhere on these topics (See Alistair Cockburn's work, for example). Suffice to say that you can drive almost the whole software process using a use-case centric approach - not that you should, of course, and the circumstances to which you are fitting a process must always be considered carefully.
Once you realise the power of well-written use cases and understand the areas in which you will use them, it seems a good idea to spend more time considering their details and form - unfortunately there is no one-shoe-fits-all approach to this as the structure of a use case is very dependent on the domain and environment in which it is being used.
One example of this is for use cases geared towards embedded systems, where I have found the assumption of everything happening in 'zero time' to be very useful - you end a use case scenario whenever you have to wait for something. This approach would be unwieldy when writing a set of high-level use cases for a user interface, on the other hand.
One can spend many hours getting a relatively small use case or set of use cases together into a usable form that may appear to be a pedantic waste of time, but to an experienced use case author is time well spent. Many lessons are learnt and dead-ends reached when going through the process of writing and using use cases 'in anger', that time spent early on considering these lessons proves very beneficial in the long run.
Subscribe to:
Posts (Atom)