One Web Day - It is about us!

Tomorrow, September 22nd, is the Second Annual One Web Day. As the OWD site proclaims: "The Web is worth celebrating. OneWebDay is one day a year when we all - everyone around the physical globe - can celebrate the Web and what it means to us as individuals, organizations, and communities."

One Web Day was started by Susan Crawford, a person of boundless energy and commitment, to celebrate the web and its contribution to the world. Many web luminaries such as Tim Berners-Lee, the father of the web, have added their message about OWD and it can be found here.

I find the web particularly special to this blog, since my web classes have introduced me to many individuals that I know and continue to communicate and share ideas solely through the web. The web has indeed provided personal and professional growth for many of us and that alone would make it worth celebrating an dreflecting on how we can make it better.

For those of you in the New York Area, you can attend activities and parties listed here.

Join in the celebration of One Web Day and visit this site for planning the third OWD. My goal is to get many educational institutions involved. Please contact me if you would like to help. Later!

Bartlett's Err, Rajapakse's Familiar Quotations

Bartlett's Familiar Quotations is a great place to explore "sound bites" from great literature. I find them useful for lectures, papers and t to explore some interesting nooks and crannies of great literature by taking the quote and then "reading around it" to get the context. In fact John Bartlett had a great quote about his quotes, "I have gathered a posie of other men's flowers, and nothing but the thread that binds them is my own."

Several weeks ago (by way of doggdot, I think) I discovered Damath Rajapakse's collection of Software Engineering quotes and had a great time sampling the quotations. Dr. Rajapakse has done a great service for software engineering students and lecturers alike. It is a highly recommended site to visit and bookmark, especially for folks interested in software engineering. Enjoy it and thanks to Dr. Rajapakse for creating such an entertaining and useful compilation.

Later!

Architectural Attributes

Hard to believe I am still working my way through posting great log entries from folks in the Spring term. This log entry from Deborah Ford in my Software Architecture and Design Class at Stevens lists great attributes for a software architect. I like that she emphasizes domain knowledge, breadth of experience, communication skills and mutual respect (architect should respect designers and developers; designers and developers and designers should respect the architect). In many ways that is a great formula for any leadership role but it is especially the case for the architect. I would like to thank Deborah for letting me share these with you. The key excerpt from Deborah's log entry:

Out of this (my experience) I’ve concluded that there are certain keys to success for architecture teams:

1. This isn’t necessarily a job for the most creative designer or best technician. It is more important to get someone who understands the big picture and can bring differing views to consensus or make a judgment when the situation calls for it.

2. Don’t farm out architecture roles to outside contractors – you are investing your knowledge capital in people who don’t have such a compelling reason to stay and can be at the whim of budgetary fluctuations. You are also giving lots of domain knowledge that your competitors may be able to take advantage of further down the line.

3. Team members should have a wide exposure and not be too wed to any particular technology or internal organization. I am wary of people who have spent their entire working career in a single organization.

4. They must be people who have the respect of the teams that they work with.

5. They must have a good grasp of the business domain.

6. They must not be seen as too allied with any single development organization

Hopefully, I will increase my volume of posts in the next few weeks since I have some backlog and a fresh stack of 30 logbooks to read from my summer classes! Later!

A Growth Opportunity

One of the management euphemisms I have heard repeatedly over the years is  "growth opportunity," generally meaning a difficult, unpleasant or impossible assignment that is usually an offer you can't refuse.  William Lapenta from the spring Stevens Quantitative Software Engineering class, wrote this entry in his log and he provides valuable suggestions on how to deal with one class of growth opportunity, being handed responsibility without the necessary authority.  I hope you enjoy it and will offer additional suggestions on how you would deal with the situation.   Later!

Responsibility Without Authority

William Lapenta

One of the toughest types of situations professionals in any area of business can find themselves in is one where they are assigned responsibility for an issue without being given the appropriate authority to complete the task at hand.  This scenario is one that can be all too familiar to the developer or Software Engineer in charge of a complex and diverse project.  It seems that software projects lend themselves to this type of problem naturally. A developer, architect or SE must learn to tread carefully to successfully navigate through these waters.

What can often happen is that you may be given the task of implementing a system or project that interfaces with several other systems not under your domain of authority.  Learning how to deal with one’s peers can be as or more important than knowing how to deal with sub-ordinates or superiors.  When the line of command is not clear I have found that the best approach can be one of using more carrots than sticks.  The best solution to a problem, where you are not getting the co-operation you believe you need from a peer, is to somehow convince that person to assist you voluntarily.  Raising the issue to a higher level of authority should be your last line of attack, even if you believe you are one hundred percent in the right. 

Some methods that you might use in cases like this are:   Appeal to your antagonist’s sense of self worth.  When soliciting a peer’s assistance, tell them how important their piece of the project is and that you understand how difficult a task you are requesting of them.  By letting them have an elevated sense of self-worth, they may just complete the task out of pride.  Give them as much positive feed back as you can for any part of the task they have already undertaken.  Let them know how grateful you will be if they can assist you and that you would repay them in kind if the need arose.  Be willing to work around their schedule. If you are at a bottleneck due to this type of situation, it is better to have to put in the extra effort resolving the problem than having to explain your failure to your superiors.

If all else fails you may need to delegate the issue upward.  By this I mean, that there sometimes comes a point when you may need to finally raise the issue to a higher level.  This step should be taken very carefully and only as a last resort.  Once a bridge is burned, it can be very difficult or impossible to rebuild.  Remember, you will most likely have to work and deal with the person you are confronting currently again in the future.  It is almost always more beneficial to bite the bullet, swallow some pride and put in the extra effort to resolve a situation amicably (at least from your foil's perspective) than to come away with a successfully resolution for your current project while leaving hard feelings and an environment of ill will with your peers behind.

The Long Haul

Larry Bernstein once counseled me that one of the worst situations is to produce a product that is slightly successful always tottering on the edge of profitability and disdain from users while requiring unappreciated heroic support from maintainers. Maxim Dzoba in his log entry for my Software Architecture and Design class at Stevens, furthers the discussion on how success should be measured. He references a post from a website which should be in your bookmarks/favorites list. It is a thought provoking entry about how and when to measure success. Later!

MAXIM DZOBA'S POST:

Learning from your mistakes.

Many programmers read worsethanfailure.com (formerly thedailywtf.com). It’s a humorous blog which pokes fun at poorly written code, poorly designed applications, and ignorant programmers or management. One time the author posted a big entry that was unlike the usual humorous posts. In it, the author took on an interesting point of view about what it means for a software project to be successful or failed. He states that the common standards for a project to be considered successful are too low. Usually, as soon as a project goes live and money is paid, it is written off as a success and its authors move on to new projects. But, in reality, the product they developed might be, and often is, difficult to use, hard to maintain, doesn’t do its job well, or contains serious design flaws. It may even limp through its lifecycle being a tremendous sink of resources. The project, in fact, may be a complete failure. The author’s main point is that the only way to judge that a project is successful, is to follow it to the end of its lifecycle. But since people consider a project to be a success at its completion, they don’t go back to analyze what mistakes were made, which leads to a more serious problem: they don’t learn from their mistakes!

I was startled to realize that ours is the only industry where a completion of a project is equivalent to being successful. A building that crumbles after a few years or a film that no one would watch are deemed failures and this makes people go back to analyze their mistakes and learn from them. In software, however, it’s likely that people do not understand the mistakes they made and, worst of all, take their bad practices on to their next projects.

Beware of the Raptor

The Raptor F-22 that is. Raptors were the hit nemesis of the Jurassic Park movies (warning Flash splash page), but evidently Raptors can be dangerous to pilots too! According to reports, when the new Lockheed F-22 Raptor crossed the International date line communication, fuel and navigation subsystems were rendered useless despite repeated reboots! Business Week adds an additional report.

It may be quite possible that you heard this but I wanted to record this for future classes and track the post mortem afterwards. If you found other sources or additional information, please add them to the comments, thanks. Later!

Simple isn't simple

This post is about John Maeda's book, The Laws of Simplicity. I just finished reading it and was simply impressed. If you read the reviews on amazon, they are mixed. I have a simpler take, read it and judge for yourself. It is a bit over $10 and 100 pages. At most it will take you the equivalent of 3 episodes of 24 to read and you will learn so much more.

I liked it a lot, will require it in many of my courses (HCI and Software Architecture and Design) and willl have several future posts on it. I have espoused simplicity and know simple isn't simple, but Maeda helps us in its pursuit. Software folks and engineers need more grounding (fore and back) in design concepts and this is a simple, gentle introduction. It is well written.

It seems appropriate to make this first post simple. For more information, Maeda has a web site. Later!