This is true of any area, but is only being properly adopted now. The example given of the Therac radiation machine is good, and serves to drive the point home. As engineers we can, and do, create products that can ave lasting effects on peoples lives. Embedded software for pacemakers, flight control software, nuclear reactor control systems, all of these things have an immediate and lasting impact, so regulation would be no small thing. Would you want your doctor practising on you after 2 years tinkering on the family gerbils?

2. Situations should be analysed ethically from first principles of moral philosophy

This is a sightly tricky one – as the text mentions moral philosophy has been hotly debated as long as man could bang two rocks together, and no definitive answer has ever emerged, nor, I personally believe, will it ever. With changing society, etc.. , how can one set of moral codes define behaviour for all time?

Leaving that aside, first principle analysis using some system, whether it be utilitarian or deontological, does at least provide some reference or framework to go on. Work out the implications, cost/benefits, for the fair treatment of all parties.

3. Sets of rules can be applied instead whenever pre-analysed situations arise

Fairly intuitive statement here. Applies to damn near anything really… The ground they’re attempting to cover is that canned responses can be used to apply to certain situations, i.e what to do if a safety critical app develops a major bug or something similar. The idea is to get across the point that there will be some form of backup I think…

4. Professional societies provide  set of rules as codes of conduct

Essentially correct. Every professional body that has ever existed (might be stretching things a bit here..) has had some set of laws that determine their actions, for both their benefit and their clients. They serve to protect everyone involved in the transaction, much like a social contract, and members must perform to the standard of these rules to gain admission and to safeguard their clients, and them, in return from the clients also.

5. Professioal societies support software practices through events and activities that share d promulgate best practices

An emergent property of the professional body or society is the code of conduct. A set of rules grows to become a code of conduct, a set of instructions for the member and org to work by. This is a fantastic development as it lays down the expected conduct of the member by the organisation, but where a lot of places fall down is enforcement. A code of conduct is absolutely no use if it is not verified and proven to be in use at any given time. For doctors, lawyers, etc… they can and will be dismissed from the professional group for lack of adherement to these codes, but there is currently no such failsafe for software developers, and there will be definitely be a need for one in the very near future.

6. Standards for software provide extra guidance, with ISO being increasingly important

Harping back to the last point – this is a step along the right road but not really far enough. An organisation can lose its ISO certification for lack of adherence to practices and guidelines, but thats about it.. They can still trade away happily without it, and quite likely retain a lot of their customer base. Some form of negative reinforcement for non-adherence will be required.

7. Process standards can be bureaucratic, displaying their military origins

I’d probably argue the point here about military implying bureaucracy, but lets continue. Oriinally this would have been true, as a lot of standards work would have come out of the military, being an area where quality was important. However, with growth and emergence of new memes such as agile processes, the bureaucratic emphasis fall away to leave a more process-centric process, odd as that may sound.

8. Internationally approved technical standards should be consulted and used in procurement and

development work

This is really just an extension of what went before – the implication that professional bodies exist coupled with codes of conduct and standards means that these should now be adopted internationally also. Not doing so, considering the global status of many of todays major suppliers, is braindead.

9. Overall processes can be certified that they comply with the relevant standards

Once both the process and the standard are sufficiently then yes I’d agree with this. The problem is that there is potential for fluffiness, vague generality creeping in here and there, interpretation of meanings and so on, which will essentially render you standards and the ceritification related to it meaningless.

Related articles by Zemanta

• Are You Agile? (feld.com)
• Combining agile development with customer development (startuplessonslearned.blogspot.com)
• The App Economy (bbc.co.uk)
• The Core Skills All Software Developers Need (basilv.com)

This has always been true. People will always suffer through short wages and privation if they feel that the environment and conditions are worth the lack of monetary reward. This entire section is focused on what the organisation needs to not only further its staff, but itself as by-product, and as a standalone development item. give staff the respect and self-respect they are entitled to, and you will begin to see a cohesive community being built.

2. Important motivation comes from the need for personal self-actualisation and social contact

It could be argued that almost all motivation ultimately comes from this need. Ultimately all of the goals, achievements, etc.. will boil down to some form of personal gain, even if its just personal satisfaction at seeing their team, or group, or family profit directly through their efforts. Self-actualisation, coupled with a need for society are major drivers, just as all motivational needs can in some way be linked to each other.

3. Personal development can be partly achieved by training to meet the employers needs

Following on from my previous statement, this fits in nicely. However, I’m not entirely happy about the connotations of the sentence. It seems to suggest that a person’s personal development is dependent on the organisation they work for, when in reality it is up to the individual. I know that in the context of what I’m studying it makes sense, I just like to nitpick sometimes.

4. Training must be supplemented by learning from experience, and socially from others within communities of practice

Decent point, basically it states that individuals cannot learn by study alone, experience, expert systems, feedback, peer communities, etc… are all required for proper development. This is true, and in a lot of cases people will accept the less formal ‘on the job’ training rather than the more formal and abstracted method.

5. Organisations are also motivated by the need to survive and grow within some wider rational and international economy

This is a wider extrapolation of the previous point. think of an organisation as a large organism, constituted by the cells of staff beavering away, learning and working within. Whenever more information is acquired and applied by one cell, it benefits that department, or system if you will, leading to overall benefits for the organism. Fitness to survive is the key here, and being able to learn and adapt are integral to this.

6. Modern economies are based on free markets which are, in turn, based on the exchange of private goods between free agents

Personally I tend to view the current global markets as closed rather than free. There is only a finite amount of physical resources available to push around to consumers, and it will not last forever. However, the concept behind the free market is good. Goods and services find their own price levels, and hold steady based on what the market will value. Cartels and monopolies are therefore a bad thing, choking trade and causing scarcity.

7. Markets adjust themselves through the signals of prices, interest rates, profits and wages to achieve optimal use of limited resources

Again on the subject of monopolies, the system only works when all agents are free, equal, and benevolent. Otherwise you get situations where competitors are choked out of business, commodities being offered at ridiculous prices, etc… The market needs to be monitored and regulated in order to work.

8. Markets fail when agents external to the transactions are also affected, either positively or negatively

This harks back to the idea of agents not directly implicit within a trade, but explicit from the internal actions, whereby a large monopoly organisation acquiring a smaller competitor indirectly harms the market by causing competition to break down and prices to rise, even though the market was not directly involved in this transaction.

9. People and organisations may operate outside the normal market within the gratis economy of voluntary labour and free use of products and services

Hooray for people! The gratis economy is basically people, or agents, giving time, money, work, whatever, to some other agent of whatever form for no return whatsoever. The OSS community is a prime sample, Ubuntu for example, and there are a myriad others out there doing similar works, Red Cross, NGOs, etc.. These actions not only bring needed commodities to those who need them, they help to regulate the free market by essentially being a free alternative to the pay options. The system works surprisingly well in this case, and long may it continue.

Related articles by Zemanta

• Managing knowledge workers: motivation and the hierarchy of needs (billbennettnz.wordpress.com)
• Why is Continuing Education Important? (continuingeducation.suite101.com)
• Nailing the myth of unregulated global capitalism (samizdata.net)

To  a point. Only after a lot of detailed examination of the organisation, the staff involved, and the knowledge and processes contained therein can any diagramming or measuring begin. Even after this point, there will still be a lot that cannot be diagrammed, or measured. This point works off the assumption that there are no unknowns and that all items can be analysed in such a manner. The information given in the previous section belies this, and as such the statement should be taken with a grain of salt.

2. These models are necessarily partial, and should not and cannot be taken to fully represent what happens in the organisation

Excellent, my work is done for me. This point is much better, and gives a better understanding of the process and the organisation. There is too much tacit/implicit knowledge and process happening within the organisation to ever fully nail it down to be a definitive model of the organisation.

3. The work of the organisations can be modeled as business processes, a sequence of interacting individual activities

In the text, as in various other industry studies performed over the years, the concept of business processes emerged, a process whereby environment (environment here meaning any interaction with external or internal demands or pressures) trigger a set of actions from the organisation and staff to perform some set list of tasks. Taken from a programming point of view this could almost be called the organisation’s business algorithm. Seems simple but it is an important concept to understand when dealing with such entities, and hasn’t been around all that long.

4. The activities in these processes can be modeled and can be made highly specialised to enhance efficiency by scientific management methods

Simple extension of previous comments. Defined as Taylorism or Fordism, these reworked processes can be applied to the organisation to provide major increases in productivity, while also bringing costs down if applied correctly. An application of modern thought to the industrial age production method of thinking, there are, however, major drawbacks to the way these methods were actually implemented.

5. These tayloristic processes lack flexibility and humanity

I’d argue with this one and say the examples given lack flexibility and humanity. A separation between the theory and the implementations are essential here, in that anything could have been produced as a new more efficient process and had the ‘taylorism’ tag applied, without being in line with the ideals of the theory. A more holistic approach would have stuck to the theory and produced better results, particularly from a worker point of view

6. An organisation contains computing systems and software embedded within it and they are inseparable from each other

Probably wouldn’t quite agree with this. Its true to a point, but it has to be remembered that while people are absolutely essential to an organisation, software is not as much of an essential item. The org can get by quite well using other software, or depending on the size, needs, etc, possibly without any at all. There will always be cases where they are inseparable, but it is important to note that it is a commodity, an asset, instead of the end of the world.

7. The software and the business processes that use software must necessarily be developed together, and though the software can be defined by a requirements document, the software cannot be understood in isolation

This is correct. Any organisation using software for a specific purpose, no matter how banal it may seem, needs to take into account the attributes and growth of the software, just as it must do for itself. Integration into business processes and practices must be fully understood before embarking on any sort of buy-in/development/etc.. of new software to facilitate some critical need.

8. Yet in order to acquire software and later evolve it we must be able to treat the software separately from other resources used in the business process

I don’t necessarily see these two points as mutually exclusive. Going back to my comment on point 6, the software is a separate yet integrated piece of infrastructure. Think of it as something modular. You fit lots of modules together to form a cohesive whole, but once thats done you can still take them back apart to form something else, leaving out entirely one of the ‘critical’ pieces.

9. The software systems embody some of the knowledge of the organisation, but cannot embody all of the the knowledge, some must remain tacit within the people involved

Absolutely true. A very large chunk of the knowledge of all groups, large or small, exists entirely in the heads of those who work there. Various methods and strategies have sprung up for the purpose of extracting and codifying this information. Situations like staff turnover, etc.., mean a lot of this knowledge is easily lost. One of the more effective methods for extraction and retention is the concept of the feedback loop, single and double. It enables an organisation to identify its tacit knowledge, and convert it into workable, teachable practices.

10. New systems are introduced either because of internal problems, or because of external business opportunities, or because of external demands

That list is not complete. It doesn’t take into account the internal opportunities and the external problems. Regardless, it is a reasonable list for detailing how changes would originate. An organisation will need to ingest a new system, revise processes, develop new practices, etc.. in response to any of these items. They cover both reactive and proactive solutions, things like introducing new features to become a market leader, or revisiting failing processes in the face of falling revenue. Any opportunity for positive change is always a good thing.

11. Rational decision making processes and return on investment calculations can only partially help justify the acquisition

This statement is something I’m not entirely comfortable with. I personally like to be able to quantify whatever comes my way, and stating that the benefits of acquiring a system can’t be fully expressed in ROI terms is something I don’t really like. However I can’t really argue with it either. The statement, according to current processes, metrics, etc.. is correct, because there are intangibles associated with such systems, and likely will be for some time. Until Skynet takes over anyway.

12. The process of introducing new systems can be viewed as a process of adaptation or learning, and the organisation does this as a learning organisation

I’m a little uneasy at the need to make a distinction here between the concept of a learning and a non learning organisation. A non learning organisation dies, simple as that. If it is not prepared to accept feedback and learn from its environment, then it is a net detractor from the business environment as a whole, and nature will take its course. The point above should be taken as the ground state for an organisation, not as something it should aspire to.

13. Organisational learning takes place in cycles as business processes are changed, knowledge is externalised, examined, restructured, consolidated and then re-internalised

This is true, but it would be nice if it wasn’t the whole story. If instead a constant cycle of information gathered, assimilated and integrated into practice then it would show that an organisation is proving its capacity to grow and outperform its competitors. For instance, in terms of a software house, developers and management need to be constantly on the lookout for new and expanded technologies and methodologies to keep them abreast of industry changes and up to speed with the latest state of the art. Cyclical BPR should be just the beginning.

14. The people in the organisation are critical in this process, and should be viewed as part of the assets of the organisation, the human capital

Dead right. People are massively important to any group, to the (obvious) point where it can’t work without them. No people, dissatisfied people, people who feel they are not being adequately rewarded by their job (rewards in terms of ‘hygienic’ needs, or Maslow’s hierarchy), make people happier and therefore more productive in their work. Treating them like machines on a factory belt will get you nowhere and is a quick and easy way to stall productivity and lose revenue. If people are viewed as assets, or better yet as stakeholders, then they are treated as people rather than cogs in the machine.

Related articles by Zemanta

• Don’t Use Smart Technologies to Do Dumb Things (blogs.harvardbusiness.org)
• Taylor’s scientific management doesn’t apply to knowledge work (billbennettnz.wordpress.com)
• Tinkering with real world BRPs (Barely Repeatable Processes) (thingamy.typepad.com)
• Business Intelligence Dies, Business Analytics Lives (arnoldit.com)

From a management perspective this is true. From a developer perspective this is largely false. The developer will know that there are often times when you can develop system updates, new architectures, etc.. at a speed that will largely satisfy most people. The problem arises with the users/market. The market will not be ready for the latest and greatest a company has to offer in the beginning, and frequently this will continue until a certain software maturity has been reached. The cost and risk factors also play large roles here. Spending, when weighed up, contrasted with all of the relevant factors and so on, will usually fall back to “If it ain’t broke….”. It frequently just isn’t cost/risk effective to update to the cutting edge, when the investment for the dull hammer has already been made and still works just fine.

2. Unless work is applied to counteract the appearance of legacy symptoms, any business-critical software is likely to become a legacy system sooner or later

Basically this statement boils down to two items: it can be maintained, or it can be evolved. Maintenance will involve fixing little bits and pieces, keeping things ticking over. Evolution will take the existing processes, tacit or otherwise, and create a newer, leaner, meaner and keener beast out of it. Its the football equivalent of keeping a team chugging along with the same players because they get along ok, and nothings reeeeeeally broken… whereas evolving the tem with new players, new trining methods, new coach, etc… will make it a world class competitor.Wrapping legacy systems, acquiring FOSS, modular development; all of these things are good and will, but its down to corporate mentality as well.. willingness to change and evolve will be core here..

3. Wrapping legacy software and it’s integration with newer software should be considered when replacement is too risky or too expensive

I’d agree and disagree here. Yes, wrapping should be considered if absolutely necessary, but NOT at the risk of compromising the system – from my point of view this would mean not wrapping if there is a reasonable justification for re-engineering the system/process/whatever, extracting all of the lessons learned from the current implementation. There should be some sort of bias in the judging system towards a new implementation, obviously backward compatible with the old junk, but this should nearly always be the best option. Preserving the old stuff for the sake of it or for penny pinching, etc, is just wrong.

4. In COTS-based projects the requirements are limited, shaped and conditioned to what the COTS vendors can offer

5. Component-based development provides value through cost efficiencies and trhough the emergent properties of the integrated applications

6. There are still limitations to the wide use of components, including issues of reliability, risk, trust and lack of support for the future evolution of the component

7. Successful open source acquisition and deployment requires tapping into other diverse sources for support and this requires a more diverse approach than when depending on a single supplier

8. Acquisition of open source software can be primarily motivated by a cost reduction strategy and not by the availability of the source code

9. Outsourcing beefits from a number of economic and technical efficiencies. However, this option may lead to a client’s loss of control over the software

10. Advances in methods and process capability of software organisations expand the types of software activities that can offshored

11. Instead of owning or licensing the software to run on your machines, you can rent time using it at some service provider

12. Software acquisition as a service (e.g. web services) requires adequate resolution of issues of responsibility, trust, risk and security

13. Software provision does not end with the selection of a source and the acquisition of the software and its documentation

14. Software acqusition consequences go beyond the immediate decision: they may have far-reaching impact

1. Software may not have brought about the economic benefits nationally that we could have anticipated

One of the understatements of the century, no matter what perspective you look at it from. Software is generally touted as the all-singing all-dancing answer to all of life’s prayers, but frequently falls short of user/stakeholder expectations.  Coming from a developer’s point of view I can easily understand this. I know how my software works, the limitations and capabilities, technical caveats and so on, but a non technical person could have real trouble. “Why doesn’t it do this?”. “Because of XXXXXX”. “… Thats a bit rubbish isn’t it..?”.

An example given is of productivity vs investment in IT over time. Studies by Landauer and others show that there was a marked drop in productivity as more and more investment in IT rolled out, but doesn’t really give much more on it than that. One thing we can infer here is that if we can make the graph go the other way, i.e. productivity rising, then we can safely assume that correct methods of software design, production, and equally as importantly use, have set in.

2. Software can fail in service often with disastrous results

Also very true. In service here meaning any production environment. If software is not correctly designed, requirements not properly and systematically elicited, if production is sloppy, testing non-existant, and without input from all relevant stakeholders, then failure is assured.This is a no-brainer. It will happen, no ifs buts or maybes.

The example given is of the Therac Radiation machines, but I prefer this one: The great Zune fiasco of 2008. Whereby someone in Microsoft had coded a specialised calendar check into the Zune software, and basically forgot about the existence of such things as leap years. In this case I’m not (solely) blaming the coder, that snippet should have been reviewed ten ways form Sunday, especially considering there’s already a trolley load of date and time functions out there.

3. Software is important in the automation of clerical functions, justified by the saving of labour costs and the increased accuracy and reliability of results

No, really? Software is not important, its critical. Not just for the automation of tasks, but for the error checking that comes with this. One tired and bored clerical officer can do the same process for the same set of files 4/5 times and come out with different answers each time. Machines don’t have this problem. If the software is told how to do it right the first time, then it will do it right the first time, and the second, and the third…

Its not so much that the cost of is justified, more that is essential..

4. Software offers new opportunities for enterprises to deliver their services and products more effectively and more efficiently, and even create new products and services

This is true – in the modern world the average business or even home cottage industry type person can get themselves online and trading away with world wide exposure for about €100. And that includes the costs of the web hosting. Without the services built on software, they wouldn’t be of particular use, but them they are invaluable.

5. Stability cannot be relied upon – change is always with us, but has become more intense the advance of technology and the globalisation that accompanies it

This is a good thing rather than anything else – the more the market/industry/scene/whatever changes, the more we will see new and innovative ways of creating and using software, often in ways never dreamed of before. Software, automation, call it what you will, it has busted its way on to the scene and has now taken complete control. It is at the core of every business (or should be), and the world economy would collapse without it.

6. Rational and scientific approaches to developing software have their limits, limits that are matched in other areas of human activity and marked as postmodern

I consider this a bit of a contentious one – there is always a lot to be said for the human approach, etc, but at the end of the day it should still all boild down to a rational approach to your process. If your methods or results can’t be analysed in some way (and I’m including as yet uncovered methods of analysis here..) then I would think that it probably isn’t all that effective. I’m not a big believer in the “limited” idea.