SOA Definition Revisited

It is time to revisit the definition of SOA. In an earlier posting I provided the following definition and suggested it may evolve.

SOA is a software architecture where the business logic is encapsulated in services and a single application may be distributed over many processors.

A service in this context is a software component which·

• Hides its implementation,
• Is based on standards,
• Is location transparent,
• Is message coupled, and
• Is accessible through defined platform independent
  interfaces.

I recently came across this definition in a book published by IBM Press (see reference below).

A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components—services—that can be reused and combined to address changing business priorities.

Beiberstein et al refer to SOA as a framework I refer to it as an architecture which should be self evident. I do not think this is an important difference. The difference suggests another layer of abstraction a littler further away from the implemented product. The Zachman framework is even more abstract though.

There is an IEEE definition for architecture it is "the fundamental organization of a [business] system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution". I think this sufficiently describes what is needed for an SOA without out going to the next level of calling it framework. I will stick with calling SOA an architecture for now, although I acknowledge that there are a number of technical, logical, and business centric models that should be documented for an SOA.

I like the reference to business processes and I compare it to my discussion of business logic although business logic is at finer grain and is within a service. There is an interesting argument that Business Process Modelling (BPM) should be separated from SOA but generally a good SOA implementation will allow an organization to implement its business process more easily than with other architectures. The BPM tool may be considered to be outside of the services but still be part of the overall SOA. I'll watch this space and consider where I draw my SOA boundary.

Standardize components (services) are obviously central to SOA. I don't think they are necessary secure components. Unsecure services can still be SOA even though it may be bad SOA and security has been a bit of a challenge for the evolution of SOA.

Reuse and combination are important outcomes of SOA but they do not necessarily define SOA.

My SOA definition above is still looking strong. It has the possible deficiency that it uses the term "Message Coupled" rather than "Loosely Coupled". "Message Coupled" is not in wide usage. While "Loosely Coupled" is in wide usage and is descriptive to a point, I found it too loose in my earlier posting and still stand by it.

References
Norbert Bieberstein; Robert G. Laird; Dr. Keith Jones; Tilak Mitra, Executing SOA: A Practical Guide for the Service-Oriented Architect, IBM Press: The developerWorks® Series, May 2008, Page 4.

The definition of Architecture can be found in IEEE Std 1471-2000 Systems and Software Engineering—Recommended Practice for Architectural Description of Software-intensive Systems [2007-07-15]

SWOT on BPM

Toward the end of a problematic first implementation of a BPM solution, I was asked to evaluate whether it was worth pursuing this for future solutions in my organisation. The result was a SWOT (Strengths Weaknesses Opportunities and Threats) Analysis in which I put the case for persisting with BPM. An edited version of this paper follows. While I echo the optimism of vendors for large organisations there some cautions and costs that need to taken into account when embarking on the journey to adopt BPM.


Background
Business Process Modelling (BPM) is a technique for implementing IT systems that makes the process explicit usually through the use of a graphical tool that allows the process to be illustrated as a flowchart. This flowchart can be implemented directly as system of integrated application and services once these application and services have been built.

The process model represents processes of an enterprise, so that the current process may be analysed and improved in future. The development of a business process model is typically performed by business analysts and managers who are seeking to improve process efficiency and quality. The process is implemented by IT staff who may be assisted by BPM tools.

In theory, BPM tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on real data. As a result, business process modelling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics. In practice, BPM tools require significant training and needs users to work closely with other specialist IT staff to implement systems using these tools.

Our organisation has acquired Aqualogic BPM which is being used to redevelop the XYZ system. Vendor X are doing the development work. Aqualogic is new to both Vendor X and our organisation. This has meant both organisations have had to undertake learning in this technology. The project has taken longer than expected. The project will cost more than expected and the support model for this technology has not yet been developed.

This paper will assess the risks involved in moving forward with BPM and advise whether we should continue with XYZ system using the BPM product.

Analysis
When looking at the benefits related to BPM a distinction needs to be made between the BPM process and the BPM tools. Our use of BPM tools so far, has been to reverse engineer the XYZ system and implement an existing process. This is not the most beneficial way to use BPM and therefore will not immediately produce any savings for XYZ system.

More benefits are likely to flow from the revision of the business processes that is inevitable with complicated processes. The mapping and refinement on business process is the same as any continuous improvement initiative.

An effective BPM implementation is much more top-down. BPM is more suited to projects that involve a significant Business Analysis effort. The analysis of the process should be conducted at the business level. The process is then refined and optimised and where possible automated.

Computer Applications are no longer written purely for discrete business units. Modern enterprise applications link different business units with ever more complex processes involving people from all over the organisation. The emerging standard approach for this is to break applications into services (Service Oriented Architect) and link these together using BPM tools. In this way BPM can support large integrated enterprise applications. Along with a portal product and an enterprise services bus, a BPM tool is a central component of the modern SOA development toolkit.

If the right skills and tools are in place, BPM promises to enable a more agile organisation. Conventionally, changing software to implement a changed business process involves editing complicated program code possibly spread over a number of different applications. With BPM the process is presented in a more intuitively obvious form and can be stored centrally rather than spread across different applications. This enables changes and therefore more business agility because of the ability to change these processes more rapidly at lower cost.

Strengths

• BPM allows the process to be viewed and communicated to non-technical users
• The BPM can be changed by staff who understand the BPM tool
• The business process is easier to follow than the corresponding Java code.
• Status can be tracked using the BPM Tool
• Possibilities for process change can be investigated using the BPM diagrams.
• Supports Services Oriented Architecture (SOA)
• Standards-based approach to integrating diverse systems and data sources.
• Engenders Continuous Process Improvement
• Improves business agility

Weakness

• Staff need to be trained to use the BPM Tool
• The organisation needs to pay significant costs to license the BPM tool (including non-production versions)
• There are more points of possible failure in production systems.
  Production systems need to be supported which may will involve extra servers.
• Business process changes normally require constant involvement of the user. (Collaborative development model). This may require more user resource but also a change in software development approach.
• The default process management screens on the BPM Tool may not be appropriate for users. In the case of XYZ system it is costing more to implement custom interfaces.

Opportunities

• We could use the models in the BPM in our Architecture repository and benefit other projects.
• Other projects will become easier to develop using BPM once we have sufficient skills and a critical mass of services that can be used with BPM.

Threats (Risks)

• The organisation may not have chosen the correct tool and this may be replaced by a competitors product in the future.
• The Aqualogic Tool may not be supported by the vendor in the future
• It is possible to map more complicated processes. There may be a tendency to get automated tools to do this rather than simplify the business process.
• There is a performance overhead in running BPM applications. This may cause programs to perform slowly and impact users.
• BPM tool support from any vendor is limited in regional locations.
• If we write custom interfaces for users to manage BPM workflow then we have to make sure these interfaces are compatible with future versions of the tool.
• Outsourcers who have forged a partnership with our organisation will be able to charge high rates to support its BPM tool.

Conclusion
The choice of BPM for XYZ System was sensible from the point of view that the system was automating complicated business processes involving different roles. The decision was not ideal because the project did not require a business analysis stage and an opportunity to refine the business process.

The XYZ system project will therefore suffer the learning curve costs of the BPM Tool. It should also reap some benefits later on for having a process that can easily be modified our organisation retains sufficient skills to do this.

The BPM version of XYZ system should still be implemented. Handover to support should involve making sure there is an adequate support model for the product. This should involve having someone in-house that can support the runtime component of the BPM Tool and assist with the design-time component with the tool.

The investment in in-house skills should be used in other projects. The identification of the potential to use BPM should made early in a project so that the Business Analysis can be done with BPM in mind.

The risks are significant but most can be addressed by acquiring the necessary skills to use the BPM tool effectively. The benefits are also significant. An effective BPM capability will assist build integrated systems effectively and efficiently, and support implementation of a Services Oriented Architecture.

References

Rudden, J, Making the Case for BPM: A Benefits Checklist, BPTrends Jan 2007, http://www.bptrends.com/publicationfiles/01-07-ART-MakingtheCaseforBPM-BenefitsChecklist-Rudden.pdf
Sinur, Jim, The Top Five Benefits That BPM Delivers Today, Feb 4 2009, http://blogs.gartner.com/jim_sinur/2009/02/04/the-top-five-benefits-that-bpm-delivers-today/
Khadye, Vinayek, Benefits of BPM Systems, 7 Mar 2005, http://it.toolbox.com/blogs/bpm-blog/bpm-series-benefits-of-bpm-systems-4837
Cooper, Mark and Patterson , Paul, Business Process Management (BPM) Definition and Solutions, May 2007, http://www.cio.com/article/106609/Business_Process_Management_BPM_Definition_and_Solutions?page=5

SOA Adoption for Dummies Such as Managers

Software AG has commissioned another SOA publication to "Dummies" series and released it to their customers. This follows on from their "BPM Basics for Dummies" book which was a referred to in an earlier post. I have to confess to listening to the podcast version of this book while watching the cricket rather than reading the book in detail the conventional way.

This book is focused on SOA Adoption rather than SOA. It is not a technical book in SOA. References to XML, SOAP and WSDL are consigned to a footnote. This book is evangelical and pitched at management. I question whether it is right to consider that dummies would be involved in SOA adoption. Your average person involved in an SOA Adoption decision is a highly credentialed senior IT manager on one hand but on the other hand the time taken over each decision of a manager can be minimal and display all the appearances of being made by a dummy.

The authors should be congratulated for taking SOA Adoption as subject in itself as it is a difficult for enterprises to adopt SOA and it is much more than just the technical challenge that needs to be addressed. The book and podcast series are well produced and easy to absorb.

Do not expect any great depth from this book however. The authors call their SOA adoption approach "Rocket Science" but this approach simply consists of:

1. Keep the pointy end of the rocket up.

2. Keep moving up.

3. Don’t stop till you are weightless.

This is good motherhood advice for any significant undertaking but I do not see it as being particularly insightful for SOA adoption.

The authors do a good job of SOA evangelism and have lived up to the creation of simple book for "Dummies" by missing a lot of the technical detail. There is nothing particularly radical in this book but it does give you some important things to watch such as SOA Governance, Organization structure, SOA infrastructure, the SOA competency centre and organization structural issues that might arise from SOA.

In summary, this is a good book to give a dummy or manager who needs to be brought on board to get with your SOA program. It will not get you to SOA weightlessness without a lot of other expertise, skills and resources. It is not the bible for someone wishing to be the main driver behind SOA adoption.

Reference

Miko Matsumura, Bjoern Brauel and Jignesh Shah, SOA Adoption for Dummies , Wiley Publishing Inc., 2009
http://www.softwareag.com/Corporate/res/books/soa_adoption_for_dummies/default.asp

SOA and Cricket

It has been a long while since I put together a blog posting. This has been for a number of reasons both personal and professional. But one reason has been the game of cricket.

I have two sons that are good at cricket and play for a local club. Most of the English-speaking world knows what Cricket is. For the Americans who may read this it is a bit like baseball. You use a bat and a ball and not much happens for long periods of time. Unlike baseball it can be played over several days for up to six hours a day. Much of my time has been involved in watching the game played by my sons but also watching the televised games between the Australian national team and the South African national team.

Progress is made slowly in cricket and it is often not clear whether you are winning until near the end of the game. The players need to stay focused on what they are trying to achieve and there are a whole range specialists (batters, bowlers and fieldsman) involved. SOA is much the same. It takes time. Since my last blog I can report some real progress from my organization but we have still only completed a small part of the journey. We need to stay focused on the desired SOA outcomes and we are gradually building a set of skills and relationships that are required to bring SOA to fruition.

I intend to prepare more blog postings shortly. The cricket season is over and the hot spell in South Australia has passed. Meanwhile my organization has completed a number of projects and has embarked on more which will advance its SOA so I have some content to provide and hopefully the motivation to provide it.

Understanding Enterprise SOA: Book Review

I was handed this book by one of my programmers. He lent it to me because he knew I was doing some reading on the subject and trying to work out how to bring my software developers up to speed with SOA. I didn't get the impression that he had got terribly much from the book himself. After reading it I can see there is benefit for managers but I think there was not enough technical meat in the book for programmers and analysts.

This book is not technical. It can be read by managers, salesmen or students and I think these were the intended audience. The explanations are easy to understand although I found them long-winded and overly simplistic on many occasions.

The authors attempted to explain procedural code as if it was museum artifact. This made me feel very old. It begs the questions whether the developers brought up on object-oriented development and SOA really need a detailed explanation of the concept of procedural code.

On the positive side this books tackles issues that others do not. It has a good non-technical discussion about security issues and there is a lot of discussion about human issues such as training, reorganization and corporate culture.

Oddly for a book written in 2006 I did not find any mention of Enterprise Service Bus (ESB) although it was clear the author was encouraging looking at off-the-shelf SOA management solutions as well as SOA security and routing software.

Eric Pulier in his preface is unbridled in his enthusiasm for SOA standards:

In a spectacular cycle of enlightened self-interest, every major company in the world has build on top of standards which have ushered a potentially exponential release of value from investments in information technology.

Elsewhere in the book there are sufficient cautions to temper this enthusiasm. In particular the authors advise that much of SOA is still hard work and that there are no industry standard solutions to problems such as transaction processing and security.

There is a long and detailed case study running through the book. The authors do not hold back on the multitude of issues that confront an organization adoption SOA. Parts are realistic and even painful for those of us who have been through implementations of a difficult project or technology.

The book has a good history of technologies and standards. The authors make a good point about standards conforming to the Tipping Point model (see references below). This is when a standard reaches a certain level adoption that it suddenly becomes desirable for the majority of developers.

This is not a strong academic text. There are not many references to other information sources. The definitions are not clearly stated and often over-simplify the concepts. Concepts like Enterprise Architecture, Real-Time Computing and loose coupling are all not accurately defined.

"Loose-Coupling" is described but not adequately explained. The authors give the impression that loose-coupling is only about where you can locate services.

Web services, in contrast are loosely coupled. Once a piece of software has been exposed as a web service it is simple to move it to another computer.

This is an important aspect of coupling but is not the whole story as I have identified on previous postings.

The book focuses on synchronous services rather than asynchronous services. This is unfortunate as other texts such as Thomas Erl or Krafzig, Banke & Slama seem to advocate asynchronous services.

The book addresses the Subject of Enterprise Architecture again loosely defined. At one point the book states

There is no institute providing credentials for enterprise architects.

I'll give the authors the benefit of doubt. Perhaps in 2006 there were not the credentials around but these days there are a number of places to get recognized credentials as an IT Architect. The Microsoft Certified Architect programs spring to mind although I will not vouch for the content of these programs.

The authors see SOA as a method for replacing parts of the Data Warehouse. I was not particularly convinced by this. This was an interesting subject which I had not seen before. I think there is benefit in moving the content of SOA logging to the data warehouse but I was not convinced that SOA radically changes the typical data warehouse ETL process.

This is not a book with detail examples of SOAP and WSDL. It will not explain how to code or build services. You will not find much detail on WS-* here either.

Contracts and Service Level Agreements (SLAs) are described in the book. The authors also introduce the Business Level Agreement (BLA). This is agreement to monitor business conditions such as an inventory pile-up causing $100k per minute of cost.

The book is well illustrated with copious diagrams and notes attached to the diagrams. I found myself skipping past a lot of the diagrams because they did not seem to be explaining anything particularly special.

I congratulate the authors for including detail about setting up training programs in the book and explaining how the resources are brought in to deal with the adoption of SOA. This is missing from many other texts and is an important issue today.

The authors emphasize that SOA is an enterprise approach. Under SOA, IT departments put in place infrastructure to serve the enterprise rather than just serving particular applications.

I would recommend other books before this one for most audiences. The simplistic and at times pedantic prose would make it hard to recommend to an IT professional. Nevertheless there are some well-made observations in this book that you are not likely to find elsewhere.

References

Understanding Enterprise SOA, Eric Pulier and Hugh Taylor with forward by Paul Gaffney, Manning, 2006

The Tipping Point: How Little Things Can Make a Big Difference (ISBN 0-316-31696-2) is a book by Malcolm Gladwell, first published by Little Brown in 2000.

Will BPM be the Savior of SOA?

My friendly Software AG representative recently gave me a copy of the "BPM Basics for Dummies". This was an interesting little book pitched at the Executive level. It would not help an IT person to get started with any particular product set but would help them understand what all the fuss was about.

BPM (see note below) has been with us since at least the 1980s. It used to a paper process of writing up the process and then getting a team of programmers to build it, then implementing it on usually a big computer that could handle it and then have the computer operators monitoring it.

In the 1990s Business Process Reengineering (BPR) was an approach which changed an organizational process. It involved process diagrams, IT change and business change.

The excitement with BPM is that some of the leg work involved in actually building systems can be removed if the components of the business process are already established. In this case the components are Web Services enabled through an SOA.

What interests me about this is that some of the concepts behind BPM are a lot easier to explain to the business than SOA. You can get out the Lego blocks and explain the benefits of agility until you are blue in the face but you are still only talking in analogies and expecting the business to take a leap of faith. If you show the business a diagram of one of their business processes and then tell the business the cost of changing that business process then that makes sense in terms the business understands. Of course there is a significant investment in infrastructure, tools and services to establish before you get to that point. It is this significant investment that the IT executive wants to sell. If you are pushing a plan to buy infrastructure, tools and establish services then the plan will make more business sense if the objective is BPM rather than SOA.

I think Software AG understands this and that is why they are giving out "BPM Basics for Dummies" and not "SOA Basics for Dummies". I think the business will get behind BPM before they will embrace SOA. We may see more push for BPM to business executives and SOA may take a back seat. The IT department however knows it needs SOA to get BPM to work. That is just how it meets the business goal of BPM.

Note:

BPM stands for Business Process Management, but you would excused for thinking it stood for Business Process Modeling. The "Management" implies that we are doing a lot more than mapping out the processes. The "Management" moves beyond documenting the processes to making them happen and monitoring their effectiveness.

This is not to be confused with BPMN (Business Process Modeling Notation) where the "M" stands for "Modeling". BPMN however can move beyond an aesthetic model to an operational system by converting it to BPEL.

References:

http://www.ebizq.net/hot_topics/bpm/

http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf

http://en.wikipedia.org/wiki/Business_process_reengineering

Kiran Garimella, Michael Lees and Bruce Williams, "BPM Basics for Dummies (Software AG Special Edition)", Wiley Publishing Inc. 2008.

Laws of Software Development

I ran across an new eponymous law while reading "Understanding Enterprise SOA" by Eric Pulier and Hugh Taylor.
Pulier's rule of reuse:

A programmer will look at another programmer's output, no matter how brilliant and declare it garbage

The best law's and rules are named by others who admire the author's work, but this one seemed pretty worthy to me. This got me reminiscing about some laws of software development that perhaps had the same rigour as Newton's Laws, Boyle's Law or Hooke's Law.

The rules I have admired during my career are:

Brooks's Law:

adding manpower to a late software project makes it later

Hofstadter's Law:

It always takes longer than you expect, even when you take Hofstadter's Law into account.

Codd's Rules of relational database management systems which I won't quote here because there are 13 of them.

Moore's Law:

The number of transistors that can be inexpensively placed on an integrated circuit is increasing exponentially, doubling approximately every two years.

This has a number of applications outside of transistors such as processing speed, memory and disk capacity.

Clarke's 3rd Law:

Any sufficiently advanced technology is indistinguishable from magic.

The reason I class this as a software development Law is that it points out the futility of trying to explain the technical details of software to Business users. If a technical decision does not have any business impact then it may as well be magic.

I thought I would check what other software development Laws there are on the net. Here is a good sample from some useful sources listed in the Bibliography below:

Amdahl’s Law

The speedup gained from running a program on a parallel computer is greatly limited by the fraction of that program that can’t be parallelized.

Asimov's laws (Yes its SF but one day a software developer might have to follow them):

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Atwood’s Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript

Bye's First Law of Model Railroading

Anytime you wish to demonstrate something, the number of faults is proportional to the number of viewers.

Clarke's 1st Law:

When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.

Clarke's 2nd Law:

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

Clarke's 4th Law (He's not often credited with this one):

For every expert there is an equal and opposite expert.

Conway's Law:

Any piece of software reflects the organizational structure that produced it.

Edwards' law

You cannot apply a technological solution to a sociological problem.

Greenspun's Tenth Rule of Programming (There actually are no rules 1 to 9)

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp

This can also be worded “Those who do not understand Lisp are doomed to reinvent it.”

Gustafson's Law (also known as Gustafson-Barsis' law)

Any sufficiently large problem can be efficiently parallelized

Kerckhoffs' law on secure cryptography

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge

Lehmann's Laws

1. Systems that are used must change or automatically become less useful
2. Through changes the structure of a system becomes ever more complex and more resources are needed to simplify it

Linus's law — named for Linus Torvalds,

given enough eyeballs, all bugs are shallow

Lubarsky's law of Cybernetic Entomology:

There is always one more bug.

McLuhan's Law:

If it works it's obsolete.

Metcalfe's law

In communications and network theory, states that the value of a system grows as approximately the square of the number of users of the system.

Murphy's Law

If anything can go wrong, it will.

Occam's Razor:
There are many wordings for Occam's razor and debate about how it is interpreted but from software development I think the best wording is "The simplest solution is usually the best". This is very nearly the same as the KISS principal "Keep it simple stupid".

Putt’s Law:

Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.

Sturgeon's Revelation (sometimes referred to as his second law):

Ninety percent of everything is crap

Weinberg’s Law:

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

Wirth's law

Software gets slower faster than hardware gets faster.

Zawinski's law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Here are still more great laws from Joey DeVilla's Blog posting.

The Law	Who Said It	What it Says
Ellison’s Law of Cryptography and Usability	Carl Ellison	The user base for strong cryptography declines by half with every additional keystroke or mouse click required to make it work.
Ellison’s Law of Data	Larry Ellison	Once the business data have been centralized and integrated, the value of the database is greater than the sum of the preexisting parts.
Flon’s Axiom	Lawrence Flon	There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.
Gilder’s Law	George Gilder	Bandwidth grows at least three times faster than computer power.
Grosch’s Law	Herb Grosch	The cost of computing systems increases as the square root of the computational power of the systems.
Hartree’s Law	Douglas Hartree	Whatever the state of a project, the time a project-leader will estimate for completion is constant.
Heisenbug Uncertainty Principle (restated)	Jim Gray	Most production software bugs are soft: they go away when you look at them.
Hoare’s Law of Large Programs	C. A. R. Hoare	Inside every large problem is a small problem struggling to get out.
Jakob’s Law of the Internet User Experience	Jakob Nielsen	Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
Joy’s Law	Bill Joy	smart(employees) = log(employees), or “No matter who you are, most of the smartest people work for someone else.”
Lister’s Law	Timothy Lister	People under time pressure don’t think faster.
Nathan’s First Law	Nathan Myhrvold	Software is a gas; it expands to fill its container.
Ninety-ninety Law	Tom Cargill	The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
Pesticide Paradox	Bruce Beizer	Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual.
Reed’s Law	David P. Reed	The utility of large networks, particularly social networks, scales exponentially with the size of the network.
Sixty-sixty Rule	Robert Glass	Sixty percent of software’s dollar is spent on maintenance, and sixty percent of that maintenance is enhancement.
Spector’s Law	Lincoln Spector	The time it takes your favorite application to complete a given task doubles with each new revision.
Spafford’s Adoption Rule	George Spafford	For just about any technology, be it an operating system, application or network, when a sufficient level of adoption is reached, that technology then becomes a threat vector.

Some unattributed "laws" that are worth mentioning:

• Build a system that even a fool can use, and only a fool would want to use it.
• Any program over 100 instructions can be simplified by 3 instructions (without losing any functionality).
• Any idiot can learn to use computers, and many do
• There’s never time to do it right in the first place, but there’s always time to do it over when it doesn’t work.

This posting started with Pulier's Law: "A programmer will look at another programmer's output, no matter how brilliant and declare it garbage". At the risk of repeating Pulier's conceit of naming law about himself I propose:
Kimber's Corollary:

No amount of documentation is ever sufficient to completely understand a system

Bibliography
http://en.wikipedia.org/wiki/Adages_named_after_people

"Moore's Law is Dead", http://www.techworld.com/opsys/news/index.cfm?newsid=3477

http://en.wikipedia.org/wiki/Change_management_(engineering), This includes the reference to Lehmann's Laws siting Hinley, D.S. (1996). Software evolution management: a process-oriented perspective. Information and Software Technology, 38, 723-730

http://en.wikipedia.org/wiki/Moore

http://en.wikipedia.org/wiki/Occam

http://www.webopedia.com/TERM/C/Codds_Rules.html

Joey de Villa, http://globalnerdy.com/2007/07/18/laws-of-software-development/

Phil Haack, 19 Eponymous Laws Of Software Development, http://haacked.com/archive/2007/07/17/the-eponymous-laws-of-software-development.aspx

Eric Pulier and Hugh Taylor, "Understanding Enterprise SOA", Manning Publications, 2006