Object Technology: Has Object-Oriented Programming Delivered?

Goth, Greg. Has Object-Oriented Programming Delivered? IEEE Software 19:5:104-107, Sep/Oct 2002.

Goth argues that using object technology to hide bugs under useless layers of inheritance means it hasn't delivered. Of course, writing spaghetti procedural code means procedural code hasn't delivered. One of the biggest problems of object technology for more than a decade has been disguising C code as C++ objects and calling it object technology.

Basili argues that it is not a clear win because we don't have enough evidence to state that it is the right way to think about design in all cases. Of course, writing a program is not the way to think about solving a problem in most cases. Does that mean that programming has not delivered?

Stensrud thinks it is good for analysis and design but not at the physical level because inheritance breaks encapsulation. This is a real problem that led to the evolution of business objects and enterprise components.

Briand says it is hard to teach newbies OO design, but that the patterns movement has provided sound recipes that have enhanced the programming discipline. It's always been hard to teach good design. Object technology just surfaces a hidden problem that has derailed legions of procedural projects.

Webster puts the blame on C++, a brittle, complex language, that a lot of programmer's have impaled themselves on. Boehm weighs in that encapsulation and information hiding are good things, but C++ wasn't really well designed for this. Good points.

Neiman has written a compelling article on embedded systems that makes the case that procedural code is better. See Embedded Systems Magazine.

Sharma makes the point that focus on the language in not the proper place to evaluate object technology. And maybe that is the most important point.

Object technology pushes the emphasis towards design and that has important implications:

1. It enabled the patterns movement, an excellent vehicle for improving the capability of all programmers.

2. It enabled component engineering which allows teams to work separately on enterprise components in a way that mitigates some of the integration disasters we had with large systems in the past.

3. It enabled smaller teams, set the stage for improvements in productivity which occur inherently in small team size, and provided an environment where agile development was feasible for large projects.

But deeper than this, maybe the most profound impact of object technology has been the ability to refactor systems on the fly (emergent architecture), allowing the evolution of a bad design to a good design, and the ability to enhance the system design during the maintenance process. For indepth analysis of the importance of refactoring, see:

Fowler, Martin et al. Refactoring: Improving the Design of Existing Code. Addison Wesley, 1999.

The impact of the ability to refactoring allowed the essential elements of lean manufacturing to be introduced to software development. Agile approaches to development capitalizes on this by working closely with customers, implementing only those features absolutely essential now, and deferring design decisions and technical implementations to as late as possible, in order to incorporate rapidly changing requirments in real time.

Mary Poppendieck provides an outstanding analysis of how the radical revolution in manufacturing in recent decades in beginning to revolutionize software development. She has published her entire new book online. Highly recommended.

Poppendieck, Mary. Lean Development: A Toolkit for Software Development Managers. Addison Wesley, 2003 (in press).

Smalltalk: Alan Kay has a Toy for You

Smalltalk is alive and well in the Squeak community. Since the inventor of Smalltalk, Alan Kay, moved to Disney and resurrected an open version of Smalltalk, the Squeak Birds of a Feather Session at OOPSLA has been a fun feature. Check out SqueakLand and you will wind up downloading a Squeak plugin to your browser. You'll feel better now that you have Smalltalk running on your computer again, despite the bugs.

>
"Etoys are computer environments that help people learn ideas by building and playing around with them. They help an "omniuser"—usually a child—create a satisfying and enjoyable computer model of the idea and give hints for how the idea can be expanded. SimStories are longer versions of Etoys that—like essays—string several ideas together to help the learner produce a deeper and more concerted project. A good motto for Etoys and SimStories is: We make, not just to have, but to know. Another motto that applies here is: Doing with images makes symbols. That is, the progression of learning moves from kinesthetic interactions with dynamic images to a symbolic expression of the idea."
-- "Etoys and SimStories in Squeak" by Alan Kay

Agile Development: XP Scales to Large Projects

Scaling Agile Methods: Can eXtreme programming work for large projects?
By Sanjay Murthi, New Architect, October 2002

From literate programming to evolutionary delivery, veteran project managers have seen a variety of shifting development methodologies. Most recently, a family of new methods has emerged united under the umbrella of "agile development." These include eXtreme programming (XP), Scrum, Feature Driven Development, and a few others.

Agile methods have introduced new practices, such as pair programming, while discarding some old ones. Agile development favors delivering working code over complete documentation, for example. Recently, top proponents of these techniques have laid out twelve principles for agile development in the form of the Agile Manifesto (www.agilemanifesto.org).

Trial By Fire
Recently, I had the opportunity to use eXtreme programming (XP) on a large software product release. The team consisted of more than fifty people located in two different development centers. At first, I was skeptical that XP could work for us. I knew that, historically, XP has been most successful with small and very committed teams, and while our team was enthusiastic and committed, we certainly weren't small.

Fortunately, the results of the experiment came as a pleasant surprise. Using XP methods, project teams were more enthusiastic and eager. People enjoyed XP's concept of pair programming and it allowed any member of the team to fix anyone else's bugs. As a manager, this reduced my stress levels when a team member was out sick or on vacation...

Security: Interview with Sun's New Chief Security Officer

The Diffie-Hellman algorithm, introduced by Whitfield Diffie and Martin Hellman in 1976, was the first system to utilize “public-key” or “asymmetric” cryptographic keys. Diffie was recently appointed CSO of Sun Microsystems. This occurred shortly after Microsoft got religion about security and appointed Scott Charney as chief security strategist at Microsoft.

Sun's Security King
Cryptography pioneer Whit Diffie offers illuminating views on his ascension to Sun Microsystems' CSO.
Interviewed by Richard Thieme. CISO, Aug 2002.

... Where are the financial incentives for businesses to invest in security?

It's still difficult to show a quantifiable return on security investment to decision makers, isn't it?

The intrinsic costs - you can now do high-grade cryptography in ordinary chips, for example - have dropped a long way. The extrinsic costs affect things like, why can't you buy a secure phone for less? This is fundamental. If you can integrate things into the product line of a major manufacturer of equipment, you can get the overhead down to where the extrinsic costs will decline and cost-based resistance will decline.

After Microsoft's announcement that security is now a priority, Sun CEO Scott McNealey said that Sun didn't need to send out a letter to make that point. Yet that was followed pretty quickly by your appointment as advocate for Sun's security offerings. Where's the distinction?

There's a rift exemplified by the difference between myself and Scott Charney, chief security strategist at Microsoft. Scott is a policeman. Police think in terms of diagnosing things and retaliating. Security people think in terms of preventing things. Neither viewpoint is comprehensive, and it's foolish to say that either alone can be entirely adequate. My prejudice is in favor of security mechanisms, denial-of-objective mechanisms - as far as possible - using intrusion detection, diagnosis and response mechanisms wherever necessary...

Mountain Goat Software on SCRUM

Mike Kohn has a nice description and presentation of the SCRUM development process on his web site. Check it out.

"Scrum works because it is a highly-empowering process that allows requirements and self-organizing teams to emerge. In their book, Schwaber and Beedle describe Scrum as an empirical process that uses frequent inspection (daily meetings), collaboration and adaptive responses. They contrast this to defined processes in which every task and outcome is defined. Defined processes work only when the inputs to the process can be perfectly defined and there is very little noise, ambiguity or change. If that doesn't sound like the software projects you work on, look into Scrum."

Agile Project Management with SCRUM

Ambler, Scott. Managers Manage. Software Development, Oct 2002, p. 43.
Scott provides a brief review of SCRUM project management. It's enough to get you started.

Also the Software Development Conference is in Boston this year, 18-22 November. Check out:

21 Nov 7:30-9pm - Agile Project Management with SCRUM - Ken Schwaber

Transforming Healthcare: The Operating Room of the Future

It always good to put object technology to some practical use. The DOD liked the white paper I co-authored with Mike Minear, CIO of the University of Maryland Medical System.

Minear, Mike and Sutherland, Jeff. Informatics - A Catalyst for Operating Room Transformation. White Paper Developed for the Telemedicine and Advanced Technology Research Center (TATRC), US Army Medical Research and Materiel Command, 2002.

How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering

Pouring new wine into old wineskins has caused problems for thousands of years. When you take an agile development process and pour it into minds and marketing machines that reproduce the same old waterfall approach complete with GANT charts, failure should not be surprising.

Three RUP experts have identified patterns of failure when using RUP and written an excellent paper that elucidates them in depth:

Larman, Craig el al. How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering. Valtech Technologies and Rational Software, 2001.

"In order to ensure absolute misunderstanding and failure in RUP adoption, we provide the following checklist or score sheet. Of course, the more points scored, the more successful the RUP failure.

You know you didn’t understand the RUP when …
o You think that inception = requirements; elaboration = design; and construction = implementation.
o You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
o You think that only prototypes are created in elaboration. In reality, the production-quality core of the risky architectural elements should be programmed in elaboration.
o You try to define most of the requirements before starting design or implementation.
o You try to define most of the design before starting implementation.
o A “long time” is spent doing requirements or design work before programming starts.
o An organization considers that a suitable iteration length is measured in months, rather than weeks.
o You think that the pre-programming phase of UML diagramming and design activities is a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code.
o You try to plan a project in detail from start to finish, allocating the work to each iteration; you try to speculatively predict all the iterations, and what will happen in each one.
o An organization wants believable plans and estimates for projects before they have entered the elaboration phase.
o An organization thinks that adopting the RUP means to do many of the possible activities and create many documents, and thinks of or experiences the RUP as a formal process with many steps to be followed.

We are confident that by ... applying the checklist of misunderstandings, your adoption of the RUP and iterative development will be a spectacular mess."
-----
More Rational whitepapers on RUP can be found on the Rational website. You won't find this paper there, however, and it may be the most important one for success. Please contact Craig Larman if you are interested in the paper.

Agile Development: Reforming Project Management

Hal Malcomber has an interesting blog on "Reforming Project Management" that focuses on lean project delivery. If you run projects you might want to be reading this. Here is an interesting recent comment that explains why SCRUM avoids GANT charts. They are guaranteed to make agile projects late!

"Experienced project managers will tell you the critical path moves on a project. Why? Tasks don’t start and finish as represented in the project schedule. This would be fine if all the performers for critical path tasks were always available to perform on the project, but this is not the case. In most organizations people are working on more than one project at a time or project work is in addition to their normal work responsibilities. This creates the situation where they must manage priorities – “Do I spend my time on this or on that?”

"We don’t know all of what must be done. Oftentimes ad hoc work (those tasks that seem to arise in the course of doing the other work) encompasses as much time as the planned work of the project. To the extent that this ad hoc work requires the same resources as the work on the plan we see projects get behind. Performing this work often shifts the critical path.

"Task durations therefore are probabilistic. They will range from times that are as short as the actual time applied performing the task to as long as multiples of the task times depending on how much waiting time and distraction time is incurred. Projects by their nature make it difficult to gauge those probability distributions because each project is unique. Our only avenue is to manage the project to minimize the variability."

Security: Top 20 Security Vulnerabilities

The U.S. General Services Administration released their updated top 20 security vulnerabilities on 2 October. These cause about 80% of the hacking incidents on the internet.

Top Vulnerabilities to Windows Systems
W1 Internet Information Services (IIS)
W2 Microsoft Data Access Components (MDAC) -- Remote Data Services
W3 Microsoft SQL Server
W4 NETBIOS -- Unprotected Windows Networking Shares
W5 Anonymous Logon -- Null Sessions
W6 LAN Manager Authentication -- Weak LM Hashing
W7 General Windows Authentication -- Accounts with No Passwords or Weak Passwords
W8 Internet Explorer
W9 Remote Registry Access
W10 Windows Scripting Host

Top Vulnerabilities to Unix Systems
U1 Remote Procedure Calls (RPC)
U2 Apache Web Server
U3 Secure Shell (SSH)
U4 Simple Network Management Protocol (SNMP)
U5 File Transfer Protocol (FTP)
U6 R-Services -- Trust Relationships
U7 Line Printer Daemon (LPD)
U8 Sendmail
U9 BIND/DNS
U10 General Unix Authentication -- Accounts with No Passwords or Weak Passwords

Faster, Better, Cheaper

Bausch, Paul et al. We Blog: Publishing Online with Weblogs. John Wiley & Sons, 2002.

The Object Technology site has been published in the format of a weblog since 1995, before the term "blogging" was coined. The new news is that there are a lot of tools now available that are more transparent to the writer than an HTML editor. Using Blogger makes posting faster and easier. This means I focus more on content and post more often.

I have been using Blogger in the background for some time now and have worked out most of the kinks. It is time to make it the main site, meaning you will see things faster and in real time. The old site is still available in the Archive. Let me know what you like and don't like.