I've just finished listening to my first few downloads of "Oracle Fusion Middleware Radio," a podcast produced by the Fusion group within Oracle.

Labels: Fusion, middleware, Oracle, TechnicalArchitecture

I made this presentation to the International Institute of Business Analysts (IIBA) in Columbus, Ohio May 2007. Google Presentations allows me to embed the PowerPoint presentation right here in my blog, so feel free to use the arrow keys to flip through the slides.

How much do I love Google??

Labels: Google Office, Google Presentations, IIBA, use cases

I received this article as an e-mail forwarded from a friend. I thought it was so appropriate for the holiday season and also for our work lives in general. I requested and received permission from the author to post it on my blogs. I don't think I have ever simultaneously posted something on both my blogs, but this article seemed to fit (for my "other" blog, see here):

Here's the article.

Counterbalance

Carol Kinsey Goman, Ph.D.

During one of AT&T's many transformations, I interviewed the woman in charge of Employee Health Services to find out what she'd observed about the most resilient people in the organization. I asked her if she noticed anything that these employees had in common that helped them deal so successfully with change: Did they work in a particular geographic region? Had they reached a certain level of the hierarchy? Did they perform similar functions? Were they male? Female? Younger? Older?

The manager told me that none of those factors made a difference. She said, "People who thrive on organizational change have two things in common: They take good care of themselves and they have outside interests."

As I continued talking with professionals in thirty organizations (and seven industries), the same theme kept repeating in my interviews. People who were the most adept at dealing with organizational change, not only had a career -- they had a life.

A definition of the word compensate is "to provide with a counterbalance or neutralizing device." Change-adept individuals compensate for the demands and pressures of business by developing counterbalancing activities in other areas of their lives. They engage in exercise programs and healthful eating habits, they cultivate interests outside of the workplace -- sports, hobbies, art, music, etc. -- that are personally fulfilling, and they have sources of emotional support. Because employees with counterbalance have fuller, richer lives, they handle business-related stress better and are more effective on the job.

They also have a source of stability - external to the organization - which many refer to as their "anchor" or "rock."

One of the most memorable interviews I conducted on this topic was with the CEO of a cellular telephone company: "I've got one of those 'anchors' in my life," he told me. "It's my sock drawer." I must have looked startled because the CEO continued quickly. "I mean it," he said. "All hell can be breaking loose at work, but when I come home at night I open my sock drawer to find everything in color-coded, neat little piles. I tell you, it does my heart good."

I've included this story in my speeches for years, and only once have I had someone take offense at it. I had addressed the national convention of a real estate firm in Florida. A sales manager from California came up to me after the speech and wanted to book a similar program for his division. "I really enjoyed your talk," he said. "But when you speak to my group, please don't make fun of the sock drawer."

I told the sales manager that I would be happy to do as he asked, but was curious about the reason for his request. He looked at me sternly. "I don't want you to make fun of it because it works! I tell all of my sales people that if they are having a terrible day, where nothing is going right, they might as well go home and straighten out their underwear drawer."

After thinking about that comment, I had to agree. It doesn't matter if the source of counterbalance sounds silly to others; change-adept people know what works for them.

Leaders who encourage employees to develop counterbalance find that, beyond building a more change-adept workforce, there are additional business benefits. The president of CalTex in Kuala Lumpur told me that his company pays for any kind of training course that employees want to take -- the only exceptions being martial arts and cooking classes. He said that the most popular course is singing lessons. This was not totally unexpected since Malaysian employees regularly frequent karaoke bars after work. What he didn't anticipate, however, was the degree to which employees' singing lessons improved their ability in giving work-related presentations. People conquered stage fright and became comfortable with standing in front of groups and expressing their ideas. In fact, the only complaint from the president of the company was, "Now they think they can sing!"

So, as this holiday season progresses, remember to take good care of yourself. Encourage your staff, co-workers and team members to visit friends, to play, to laugh, to straighten out their underwear drawers - and to sing. Doing so will result in a more resilient organization. And that is very
good for business.

Happy Holidays!

Carol Kinsey Goman, Ph.D., is a coach, consultant, and keynote speaker who helps her clients thrive on change. She addresses association, government, and business audiences around the world. She is the author of ten books including "This Isn't the Company I Joined - How to Lead in a Business Turned Upside Down." Her newest book, "THE NONVERBAL ADVANTAGE - Secrets and Science of Body Language at Work," will be published by Berrett-Koehler in May 2008. For more information, contact Carol by phone: 510-526-1727, email: CGoman@CKG.com, or through her website: http://www.CKG.com.
--

Carol Kinsey Goman, Ph.D.
Kinsey Consulting Services

Carol coaches executives, facilitates management retreats, helps change teams develop strategies, and delivers keynote speeches and seminars to association and business audiences around the world. She can be reached by phone: +1-510-526-1727, email: CGoman@CKG.com, or through her website: www.CKG.com.

Author of nine books, including:
* This Isn't the Company I Joined -- How to Lead in a Business Turned Upside Down
* Ghost Story: A Modern Business Fable
* Creativity in Business
* Change-Busting: 50 Ways to Sabotage Organizational Change
* Adapting to Change: Making it Work for You
* The Human Side of High-Tech

Labels: Change Management, Life Work Balance

I have great news! I found a very interesting book called "Republic - A Novel of America's Future" written by Charles Sheehan-Miles. You can purchase the book at Amazon.com, or you can listen to the author tell the entire story for free as a "podiobook" (mashup of podcast and audiobook).

Labels: books, ScienceFiction

One of the most important books ever written in the computer industry was "Peopleware" by Tom DeMarco and Timothy Lister. Here was a book that looked at how we could approach a software project, not only from a technical perspective, but from a people perspective as well.

If you had to sum up this book in a few words, what would you say? It's oversimplification, of course, but you could say that the main message that the book is dedicated to helping us understand that we should "be nice." Managers should treat their employees with more respect, co-workers should help each other out more often.

This isn't a bad message for us to hear. Too often, our workplaces deteriorate into overly competitive, back-biting hostile places. Being nice to each other is a very good start to a more productive environment.

But is "being nice" enough? If you've had the experience of having a "nice" boss who couldn't bring themselves to ask their subordinates to do their work, you know that being nice has its limitations. I worked with one boss who was very charming and as nice as could be, but his project was a complete failure because he was afraid to ask his people to get things done, and tended to vacillate in his opinions to whatever the last person he talked with was trying to convince him.

Again, being nice itself is not the problem. But it isn't the entire solution either. We need more than just a boost in courteousness and respect for one another. We need trust.

Employees need to trust that management is considering what's best for them in context of what's best for the company. Managers need to trust that employees will do their work.

And, unfortunately, trust is a much more complex animal than niceness.

Labels: management, niceness, peopleware, timothy lister, tom demarco

The Business Software Alliance (BSA), an industry group comprised of Microsoft, Adobe and others, announced that, for a limited time, they are awarding up to one million dollars to employees who rat out their employers for pirating software.


The award ceiling is raised until October, when it is scheduled to expire.


As a business owner, does this seem like it might affect you? "Not I," you protest, "My business does not pirate software." I'm sure that's true, but if a disgruntled employee reports you to the BSA for big bucks, did you know that the onus will be entirely yours to prove that each and every copy of each and every program and operating system is legit? Hope you kept extensive documentation, receipts and license stickers for all that stuff.


The number of "false positives" will undoubtedly be high, especially as the reward amounts increase. So you'll be at risk no matter whether you are pirating or not. The BSA will be after you for some type of settlement, even if only your record-keeping, not your ethics, is to blame. As a business owner, I believe there is a far better choice, a decision that you need to make right now.

Choose open source software.

And there will be no whining about how there is no vendor to support you. I've had exponentially better treatment posting an issue on an open source bulletin board and getting help from the community of developers than I've ever had calling a large corporation like Microsoft to get a bug resolved.

And now, there is a legitimate open source choice for almost every category of software your company needs.

• Operating System ----- Ubuntu
• Office Suite ----- OpenOffice.org
• Browser ----- Firefox
• Enterprise Resource Planning (ERP) software ----- Compiere
• Customer Relationship Management (CRM) software ----- SugarCRM
• Personal Information Manager (PIM) ----- Nomad
• photo image manipulation software ----- GIMP
• e-mail client software ----- Thunderbird

For the categories where you can't find a suitable open source candidate, you can also choose from the wide range of SaaS (software as a service) products available, many of them free. The free Saas products, of course, will not give you problems with the BSA, and the paid SaaS products won't either, because it is very cut-and-dried as to how many people are using the "service" - the vendor always has exact records on your company's usage. It is very difficult to cheat, and you certainly can't cheat without knowing it (unlike with shrinkwrapped software).

My favorite SaaS products are:

• To Do List manager ----- Remember the Milk
• RSS reader ----- Google Reader
• Collaborative office suite ----- Google Docs and Spreadsheets

There are literally hundreds more, and you can even search a list of them using SimpleSpark.

Whether you choose open source or SaaS, no Business Software Alliance alleging that you stole their software. (Just imagine the expense of the audit, nevermind the expense of documenting your compliance with each and every license.)

No licensing costs at all. And, if the software doesn't do quite what you want (especially in the case of ERP, CRM), change it! Go look at the source code, make the changes to fit your business. Put it in a separate module so you can easily upgrade the next time the open source community issues an upgrade (also free).

What are you waiting for?

Labels: BSA, Business Software Alliance, Compiere, Firefox, GIMP, Nomad, open source, OpenOffice.org, software as a service, SugarCRM, Ubuntu

SimpleSpark is a search engine for online services and tools. It includes "software as a service" Websites like Yahoo Calendar, CafePress (imprinted merchandise), Remember the Milk (task manager) --- you name it! It is tremendously easy to use.

Try it! Type in "spreadsheet" and you'll get the normal choices of Google Docs and Spreadsheets, Zoho Office and ThinkFree, but you also get another eleven other choices! That's a lot of spreadsheet choice.

I'm pretty impressed. I think the downside I noticed is that it seems to be based on the developers adding their own Web services to the list. So if a site hasn't heard about SimpleSpark, they won't be there automatically. For instance, probably the best online personal training Website HyperStrike, isn't on the list for Health. Plus, the tagging structure is a bit messed up. When I search for "social networking" I cannot find the holistic networking site Zaadz, but when I type "social networks" it is there. That's confusing!

Let me know what you think of it. It's so nice to have so many choices in one place. If anything, SimpleSpark seems to cater to the smallest of the dotcoms here, which is nice. It's pretty easy to find the big guys, but in most searches I've done here, I don't recognize 90% of the choices, which means it's always a learning experience. Now I don't have to wade through thousands of TechCrunch postings to find that cool new service that I heard about once from somebody.

Oh, did I mention? Everything has RSS feeds. I mean everything. Every search list, a "newest" list on every category. Damn, I love that.

Labels: SimpleSpark, software as a service, Web services

Lifehack.org has a great post today about the other things in life that could be done as open source projects besides software. You know we have great operating systems, office suites, graphics packages and browsers that are open source.

But this post suggests we take this effective process to greater lengths. What about open source government? Open source money? Schools? Corporations? Entertainment?

Unfortunately, the post doesn't currently load in my browser (I read it through my RSS Reader) but hopefully they will fix that page soon. It is the most thought-provoking article I've read in months. I think we should try it with some small town first, and then keep scaling up until we have a fully open source federal government!

What do you think?

Labels: government, open source

I've been known to switch browsers quite compulsively since my first days on the Internet. I started with Netscape, switched to Internet Explorer, back to Netscape, then jumped on the Firefox bandwagon as soon as it came out. And of course I tried Safari.

I've always loved Firefox, but when a separate project started at the Mozilla group for an open source browser that was specifically made for the Mac, I was all ears.

The browser is called Camino. It has much of the Firefox guts in it, but it has a distinctly Mac look and feel. I like it. It's easy to use, eminently stable and seems to handle most Web pages with aplomb.

If you're a Mac user, you should really try Camino. It is free (aren't they all?) and it's easy to install. You can even import your Firefox, Safari or IE bookmarks.

The only big thing I miss from Firefox is the type-ahead feature in the Google box. That is so convenient. I'm sure Camino will be jumping on that soon too, probably when Camino 2.0 hits the streets. It's a good thing for them to build in, because it actually makes them a ton of money. Google pays Firefox everytime someone uses that little box and then later clicks on a Google ad.

I've been avoiding using Windows as much as possible, especially since the advent of "Windows Genuine Advantage" which is an onerous anti-piracy program that comes with each copy of Windows.

Unfortunately, I have to use Windows for my clients, and today I finally relented and clicked OK to it installing a new security update or whatever.

And what happened?

Windows Genuine Advantage went through the entire installation process, then proceeded to abort (see above). I had to kill the program with Task Manager. Now I'm paranoid that it is going to give me a bunch of crap about my copy of Windows not being "genuine." Mmm, about that "genuine advantage" that I was supposed to be getting, it appears the only advantage belongs to Microsoft (and even then...).


Microsoft, you need to keep your customers in mind above your own needs. If you're going to put crap like Genuine Advantage on your operating system, make sure it works cleanly and seamlessly. I don't want error messages like this, and I'm sure other Windows users don't either.

Labels: anti-piracy, error messages, Microsoft, Windows, Windows Genuine Advantage

In a masterful move, Apple has struck a deal with struggling major music label EMI, to sell their music on iTunes without the troublesome, annoying digital rights management (DRM) encoded into it.

The songs available under Apple's new "iTunes Plus" service will be AAC encoded, but will not have any restrictions as to where you can play them. For instance, with the older-style iTunes songs, you could only really play them on your PC or Mac, or on your iPod. You couldn't use any other portable music players or software to listen to your music.

Now that has all changed. You can listen to these AAC songs (similar to the MP3 format) on any player that can play AAC, which is most of them. Not just iPods anymore.

These new song formats cost a little more ($1.29 vs $.99), but the additional freedom is worth more. Plus, they are recorded at a higher quality, making playback very close to CD-quality.

I want to say THANK YOU to Apple from the bottom of my heart. I sure this was a harrowing negotiation with EMI, and I'm sure you had to be patient through all kinds of foot-dragging, wailing and gnashing of teeth, but you did it. We, your customers and lovers of music, appreciate it. I am certain that the success that Apple and EMI will experience as a result of this groundbreaking move will encourage the rest of the music industry to follow suit and then, hopefully, the movie industry as well.

Labels: apple, DRM, EMI, Hollywood, ipod, itunes, music industry

photo: Grace Hopper known as "Grandma COBOL" for her role in creating the COBOL language

Computerworld gives us an interesting list of the top "dead or dying" computer skills. Topping the list? COBOL. It is easy for me to remember when some of these skills were the "gotta have" certifications and skills in the industry. Remember "Certified NetWare Engineers?" If you had your CNE, you were able to get work almost anywhere. And PowerBuilder? This is a cool list. I enjoyed walking down memory lane.

I have to say there was one more thing that I associate with that era. Reading Computerworld magazine...

Labels: Computerworld, technology fashions

I caught the flu this week so I've been watching a ton of TV. For some reason, when I'm sick, I can't read, it makes me dizzy.

I watched an old movie called "Desk Set" with Katharine Hepburn and Spencer Tracy this afternoon. Tracy plays possibly the first computer geek ever represented on the silver screen. He is an "efficiency expert" (..but please call me a methods engineer, that other term is so outdated...) who is going to bring in a new computer system into a research department staffed by four highly efficient female researchers.

He begins to brag about his new computer, called the Eminac, I think, and he says "Did you see it translate Chinese into Russian?" Hepburn says "Oh yes, I saw that."

There is an undertone to their conversation that a computer's ability to translate one language to another flawlessly is something that is "just around the corner."

Guess when this movie hit the theaters? 1957. Fifty years ago. Fifty years ago we were assuming that human language translation was just about possible for computers. Today, we are assuming the same thing.

When do we give up? Is fifty years enough? Just try Google Translator for a few phrases. You will get a great laugh at the results. If the phrase is simple enough, you might get a general understanding of what the original language phrase meant, but anything the least bit complex or subtle falls apart completely.

Try "How do you get to the bus?" Go from English to Italian, then paste the Italian phrase back in and translate back to English. You get "How you obtain to a bus?" You're trying to find a bus to take you downtown, and your Italian friend is thinking you want to buy a bus.

We have been "so close" to having our computers translate human languages for fifty years, and yet we still don't think we could possibly be barking up the wrong tree. Perhaps human language is too dynamic and subtle for any computer, today, tomorrow or a hundred years from now, to deal with.

That's why Hong and I are writing about the OPERA model. To highlight the power and fraility of the machine model of thinking.

By the way, who is the Katharine Hepburn in today's acting world? I positively can't think of a single actress who has filled her shoes. Can you?

Labels: early computers, language translation, machine model

This is a fun post. A librarian in a small town in Vermont received three donated PCs but not any legitimate operating systems, so she decided to install Ubuntu on them.

Ubuntu is a flavor of Linux that is known for being especially easy-to-use and has a strikingly beautiful user interface. It is downloadable for free, which made it interesting to our Vermont librarian.

I highly recommend her short video. Her enthusiasm for this great, open source software is contagious.

I'd love to try Ubuntu when I have the time to play with it. I like the look of it from the screenshots. I have several Linspire laptops, which are very functional, but the user interface just isn't as pretty as Ubuntu.

Labels: Linspire, Linux, open source, operating systems, Ubuntu, Vermont

Professor Michael Collins of the University of Toronto gives us this definition of structural engineering in the podcast "Big Ideas." The lecture is called "In Search of Elegance."

Structural engineering is the art of molding materials we do not really understand into shapes we cannot really analyze so as to withstand forces we cannot really assess in such a way that the public does not really suspect.

Any thoughts about how this reflects on software engineering?

Listen to the entire podcast (or watch!) here.

Here is another idea while we are writing the book "Beyond Agile - What is Wrong with Agile Development and How to Fix It to Scale Massively and Succeed Consistently."

In the 1970s, we had several competing methodologies: IBM's SDM/70, Arthur Andersen's Method/1 and many more. It seemed like these methodologies had many differentiators, but, looking back with 20/20 vision, they were more the same than different. They were all all "waterfall" methodologies, meaning that they advocated that we completely finish each phase - requirements, analysis, design, coding, testing, etc. - before proceeding to the next phase.

This model has an interesting history. The term "waterfall" was coined by Walker Royce, one of the first prominent methodologists in the computer field. Royce proposed this model, but then immediately noted what flaws existed in it and suggested improvements, including feedback loops from testing back to design. However, the industry seized on Royce's "initial model" of waterfall and built all methodologies based on Royce's admittedly flawed approach. We are told that Royce was not pleased with this, but his voice was lost in the noise.

Very soon after, Fred Brooks wrote the book "Mythical Man Month" which proposed a very different way of software development. Reading the book today, a reader could be forgiven for thinking it was written by the latest, hipest XP/Agile/Scrum evangelist, when, in fact, it was first published over thirty years ago. Tight feedback loops, iterative/incremental lifecycles, deep involvement of the business users were all concepts proposed by Brooks.

In the 1980s, detailed processes like James Martin's Information Engineering and Yourdon/DeMarco's Structured Analysis and Design claimed prominence. These were also waterfall processes, and continued with a focus on rigorous, extensive piles of documentation throughout the lifecycle, making any possibility of change more and more difficult as a project progresses through its phases.

In the 1990s, there was plenty of momentum for waterfall lifecycles, with IBM introducing a new waterfall lifecycle called AD/Cycle and Andersen Consulting even, somewhat inexplicably, introduced a new waterfall process in the late 1990s called "Business Intelligence" (not related to data warehousing). The 1990s was also when the CASE tool phenomenon hit our industry - Computer Aided Software Engineering. Six figure tools like Application Development Workbench (ADW) and the Information Engineering Facility (IEF) were purchased by many IT departments in hopes of reducing time-to-market of software applications. Instead, these costly tools only served to lengthened the development lifecycle, handcuff the developers in their implementation choices, and frustrate business users and their ever-changing demands. CASE tools, also called I-CASE (Integrated CASE) could possibly have been our biggest mistake so far in this industry (although we did learn some good things from our CASE experiences, so nothing is a complete loss).

In the late 1990s, the most noteworthy event in the methodology world was when Rational Software introduced the Rational Unified Process (RUP). It was heralded as possibly a process that could unite the industry, in the same way the Unified Modeling Language (UML) had done for notation of diagrams and models. The RUP included all the latest ideas in software development, iterative/incremental lifecycle, use cases, automated testing, traceability, object-oriented design and construction, component-based development, architecture-centric - you name a buzzword, RUP had it.

But RUP was no sooner out of the chute than a series of books was written pointing to the "new" great white way - eXtreme Programming (XP). XP could hardly be called a methodology, instead it was a collection of "best practices" taken from a failed project at Chrysler called the C3 Project. The proponents of XP were already well known in the industry, having led the practice of "Class-Responsibility-Collaboration Cards" or CRC Card sessions, which remains a successful technique to this day.

Again, XP hardly had a chance to gain ground before a high-profile meeting of methodologists at a ski resort in Utah brought us "Agile Development." Agile was an extension, not a dismissal of, XP. The Agile banner allowed multiple people to proclaim their adherence to a certain set of baseline principles, while varying their own processes slightly to maintain autonomy of their individual brands. Today, under Agile, we have XP, Scrum, Crystal, Lean Systems Development, Feature Driven Development and Dynamic Systems Development (among others). Even the proponents of these processes would admit that these approaches have much more in common than they have differentiators. That can largely be attributed to the first meeting at the ski resort of the industry experts who agreed to basically be cooperative rather than political about managing the competition between ideas.

Why has our industry faced such tremendous change in our short history? Every five to eight years, we seem to completely overhaul our view of software development. We jump from one train-of-thought to another, always hoping to find something that will help, and (so far, at least) always being disappointed.

Most notably, all this change has not led us to converge on a single, best answer, but, instead we've been seesawing from waterfall to iterative, from lots of documentation to none, from involving the business users to pushing them away, from trying to automate our processes to doing things manually.

One client I was consulting with last year was moving steadily toward an iterative/incremental, use case driven lifecycle. Suddenly, with the installation of a new CIO, they've jumped back into the waterfall camp and have forgotten about use cases as well.

Why do we play these games of "Methodology Musical Chairs?"

Should computer methodologies resemble hairstyles? If you substitute an afro for Method/1, big hair for SA/SD, and a buzz cut for XP, isn't it kind of a true statement that we have methodology "fashions" that closely mirror those hairstyles from days gone by? Is that what we want? Isn't there more to software development than jumping from fad to fad?

Let's examine a little closer what these "fashions" are based on. It's fairly safe to say that each of the new trends in methodology are based on someone's experiences. A highly intelligent person looks at what is working on their own projects and what isn't working, and begins to experiment. If they find something that works, maybe they write a book about it.

That is certainly how our book "Use Cases: Requirements in Context" was written. Eamonn Guiney and I noticed that requirements phases were going very poorly on certain projects, but that the approaches using use cases seemed to work better. When we noticed this trend, we began paying more and more attention to the "best practices" of requirements on our teams, and the book resulted from those observations.

But are best practices the right way to develop methodologies? See our post on best practices here.

Perhaps it's time to come up with a new way of coming up with methodologies.

Aristotle, having sough knowledge at the feet of Plato, was also an icon of big thinking. After already establishing species categorizations in biology and many other accomplishments, he set his mind on a new topic - work.

How does work get done? How do our own thoughts get translated into work getting accomplished?

Aristotle found a sculptor that he respected, and decided to observe him doing his work. Aristotle put the aspects of the work that he saw being accomplished into four different categories:

- the effort of the sculptor in doing the work
- the plan or methodology the sculptor was following, shaped by his years of experience and his long apprenticeship when he was younger
- the materials going into the work, like the stone block, the tools, the brushes
- the benefactor of the work, the person who had commissioned the sculptor and without whom this entire project could not happen

Aristotle named these aspects of the work "causes." We must take the meaning of this word in context, because it is not the same as the "cause and effect" term we use today. In Aristotle's thinking, these causes were more like aspects or forces at work in this situation. To be completely accurate, you could call them "entailments."

Efficient Cause - the effort of the sculptor
Formal Cause - plan or methodology
Material Cause - raw materials and tools
Final Cause - benefactor


This example of the sculptor is very useful to examine how work gets done. Let's try applying it to the creation of software.

For a software project being done in-house, let's say, what are the correlations of each Aristotelean "causes:"

Efficient cause - this is the effort of the team doing the work - the programmers, designers, database administrators, requirements analysts, project managers, testers, technical architects

Formal Cause - the methodology the team is following. However, it's much more than just whether we're using Agile, Unified Process, waterfall, etc. It's everything about how we work and plan. It turns out to be a multi-layered set of instructions that come largely, not from an Agile textbook, but from our own experiences of what works and what doesn't. The plan we follow and "how we work" depends on who is on the team.

Material Cause - Ah, this is a little tricky. What are the raw materials of software development? Yes, the development boxes and IDEs are our tools, but what is the equivalent of our "stone block." The material cause of our software is actually our own thoughts. Software comes from the minds of the analysts, designers, programmers, testers. And we are interpreting what comes from the minds of the end users, the businesspeople who will use our application.

Final Cause - This is also not as simple as it seems. Sure, our end users are the final cause. But what about the executive stakeholders? The ones who pay the bills? And sometimes the people who own the data for the application are not the ones who will use it (like in an Executive Information System). Then who is the final cause? A project team needs a clear final cause. One group of businesspeople who are charged by the company with making the decisions for this application. It might be a steering committee or something similar. They are the final cause.

Let's go back to the sculptor for a minute.

This gets really interesting when we think of the best practices concept in terms of the sculptor.

Imagine you have a master sculptor and a novice sculptor doing their work side by side.

You watch them both, and they seem to be doing the work exactly the same way. They put the chisel on the rock, chip a little away, then move the chisel, chip again, then step back, look at it, move in again, chip again.

But, when they are finished, you can definitely tell the difference. The master sculptor's work looks beautiful and lifelike. The amateur's looks ragged and lopsided.

So, how do you teach the amateur the "best practices" of the master?

This is where it gets goofy. I just imagine some Accenture guy coming into the room and examining EXACTLY how the master holds the chisel, measuring the number of times the master steps back from the statue to look at the big picture, putting little pit marks into a second chisel so it matches the master's chisel.

Then the Accenture guy goes to the amateur and teaches the "best practices" to him. Voila! The result is --- the same thing. The amateur's sculpture is not helped by holding the chisel in a different way, or by stepping back more often, or with the additional pit marks.

And the Accenture guy gets fired - as usual.

So what is the difference between the amateur and the master?

Here it is. (We need to now revisit the four causes.)

The master does one important thing that the amateur doesn't do yet. Remember, as the sculptor, he is the efficient cause. His tools and the stone are the material cause. His plan/methodology is the formal cause. And the final cause is his customer.

As the master (efficient) is working with the stone (material), he is constantly revising his plan (formal) based on what he sees happening as he moves toward what the benefactor (final) wants.

Bit by bit, he changes what he is doing based on what he sees is happening. It might be shaving off a bit here, or being more gentle there. He adjusts his plan constantly, or, you could say, iteratively and incrementally.

It's one thing to say that the sculptor is sculpting iteratively and incrementally. Of course he is, so is the amateur.

But the master is also revising his methodology iteratively and incrementally too. The amateur is not. The amateur starts out with his plan and runs with it. Once he gets to the end, he realizes his mistakes, adjusts for them and tries to make a better sculpture next time, but this sculpture remains a mess. The amateur might see what is happening much later and try to "fix it" with some late changes, but it won't work.

Once the amateur realizes that he needs to be changing his game plan constantly, revising what he thinks the next set of steps are, he's moved to a much higher level. And it has NOTHING to do with "best practices," the chisel grip, the big picture step-backs, or anything else. He will naturally do those things right once he can take the leap of iterative/incremental plan changing to heart.

How many times have I heard from team members "I don't want to be on the testing team! It's just mechanical work."

I've always tried to convince them that they were wrong. That testing was as creative a process as software development itself. Most of the time, I could convince people that it was true, but not always.

In our discussions about our book "Beyond Agile," Hong came up with the perfect point on this.

"If testing were mechanical," Hong said yesterday, "Microsoft would have already won the battle against spyware, viruses and spam."

What is the definition of a computer virus? It's a program that "found a hole" in your software and exploited it.

If testing were mechanical, we would have an ironclad path to sealing up all the "holes" in software and there would be no virus problem. No spyware problem.

Even spam is just e-mail that evades the software filters that are built into our e-mail clients, exploiting one hole after another.

If software testing were mechanical, a fully-tested application would have no susceptibility to viruses, spyware or spam.

And it would have no bugs. Have you ever used an application that has NO BUGS? I certainly haven't.

No, testing is a highly creative, heroic job. Underappreciated in certain companies? Sure. But the job itself is every bit as challenging, as rewarding, as creative and as interesting as designing or creating code.

Wagner's paper (abstract only) is available here.

Erica Wagner, working for an Ivy League college as a contractor, had the opportunity to watch "best practices" being created up close and personal. Her experience was less than positive.

She participated in a joint development with an Enterprise Resource Planning software company, creating an ERP system meant especially for college grant management.

She had an idea of what best practices meant. She thought there would be certain ideas at her college that the software vendor would note as working well, and those processes would be inculcated into the software itself, embodying one best practice after another.

The college and the software vendor planned to sell this set of best practices embodied in software to other colleges, making a tidy profit for both.

But Dr. Wagner's experiences of the discovery of best practices was much different than her expectations. Best practices were decided arbitrarily, based on concepts that had no basis in reality, and were "tested" only in a political sense.

The executives of the software vendor and the some of the upper level managers at the college decided that the budgeting method needed to be switched from the well-known Commitment Accounting (CA) to the lesser-known Time-Phased Budgeting (TPB). They saw TPB as a successful system in private industry, and decided it should be applied to the college's grant management. This, despite the fact that it had never been used at any college for this purpose (or any purpose).

This "best practice" didn't work out so well at the college. The researchers didn't see any point in changing to a new budgeting system, especially when their existing system has no actual problem. The problems that did exist were traced back to lack of integration between departments, not an incorrect budgeting system.

But guess which side won? The side searching for the actual best practices, or the side that had already decided what concept represented the "best practice?"

The college put the new budgeting system into the software, dubbed it as a "best practice" and subsequently sold it as such to other colleges, much to the chagrin of the researchers.

The college also had to create two new departments to convert the still prevalent CA budgets into TPB budgets so the ERP system could understand the figures. The TPB information was not used by anyone.

It's not hard to imagine that this is a fairly common process for creating best practices in ERP software.

And ERP is not the only perpetrator of best practices. I've been a computer consultant for more than twenty years, and I can say from experience that consultants make a lot of money taking the "best practices" from one client and applying them to another.

So what's the problem with best practices when not codified into a computer program (like ERP)?

Let's go back to the original definition of "best practice." Lynda Gratton and Sumantra Ghoshal write, in their article in the MIT Sloan Review, that best practices are "developed outside a business unit or company and then brought into adopting organizations in an attempt to get them on a level playing field with their competitive set."

There's a little bit of "Everyone's doing it, why don't we?" involved in the idea of best practices.

NOTE: The investment community has even bought into best practices and ERP, to the extent that they often give a higher stock valuation to a company that has implemented an ERP package than one that hasn't. This is how far the myth of best practices and ERP has travelled.

But the problem, as Gratton and Ghoshal point out, is that part of an organization's own competitive advantage is likely their own "signature processes," those that make them unique and that work particularly well for their own organization. It's what "makes us us."

And there's another dangerous assumption with best practices. Let's say we decide to take a project estimation process from Company A and implement it at Company B.

We've already covered that this "process copying" makes the assumption that Company B has no signature processes that are worthwhile. But the second problematic assumption is that the people inside Company A and Company B are identical. That they work the same way, have the same motivations, share the same culture.

This assumption is not correct. Just as every organization is different, so every person is different. Even trying to copy a process from one department in Company B to another department in Company B will have problems. We know this from experience. Why? Everyone is different.

Using our example, let's say that Company A is staffed with a lot of young, ambitious grads from business school. Company B is staffed with employees with more than 10 years experience in their current jobs.

We saw evidence of this at a software product company a couple of years ago. One team was incredibly successful at creating a productive software development process, building a monstrously large, complex product in a matter of months. However, they relied heavily on a hyper-productive project manager / technical architect in the middle of it all who was able to hold all the concepts of what needed to be done inside his head and was happy to explain it to anyone who needed to know. Other project teams tried to copy this successful approach, but each one failed because they didn't have a replica of that amazing guy. It just didn't work. They needed something that fit their own situation, their own staff.

We will also set up a related podcast, which we haven't done yet. We'll podcast our twice monthly discussions.

UPDATE: A podcast right now looks doubtful. We're spending a lot more time just writing the book and probably won't have time to edit and post podcasts.

This is our new blog for discussing the book on "Connected Software Development" or whatever we're going to call it.

This book is based on Dr. Hong Li's theory of the Organic Purdue Enterprise Reference Architecture (OPERA), and focused on software development.

Contributors are Hong Li and Daryl Kulak (known as Holistic Economy in the blogosphere).