|
|
-
This has nothing to do with architecture or software development: http://jules.unavco.org/ a site where you can graphically examine geophysical data including things like fault zones, earthquakes, and volcanoes, as well as earth at night, etc. It also has displayable information on other planets in the solar system.
|
-
I use the contrasting metaphors of the sailboat and the locomotive to illustrate the value of the iterative approach, But is the locomotive really that bad? Is a waterfall process “water folly”? And is the sailboat really all that flexible? Let’s go a level deeper. Instead of analogizing locomotive operations to software development, let’s instead map locomotive operations to data center operations, where very specific, dependable and by-the-clock predictability are expected and valued. And let’s make the locomotive analogy of software development the building of the transcontinental railroad. From this viewpoint the locomotive is a much more dynamic environment. A number of elements are immediately seen as good and useful to consider in the context of software, for example: - Know the terrain before you start building a section of track
- Progress in stages (sections of track)
- Have a repeatable process for the stages that you improve as you go
- Make sure the staff knows their responsibilities and has the tools they need
- Have adequate materials available to continue the work
- Build each stage as a series of layers (roadbed prep, ties, track)
- Comprehend, anticipate, and include the politics of what path you take and do not take (what towns will be bypassed, and which serviced)
The leaders of the transcontinental railroad project had to be flexible enough to cope with everything from weather to indigenous property owners. Is sailing so completely wild and unpredictable? Not if you want to be successful at it. The captain and crew of a sailboat must be thoroughly trained in the appropriate processes, terminology, operations, and practices. They must work as a team, and do specific things in specific situations quickly and correctly. Navigation is not just random steering and adjustment as the wind blows or the current changes, but begins with good maps and knowledge of the territory to be explored. There are milestones that are checked (positional, landmark, etc) against specific transit times to insure appropriate progress is being made. By the way, if you really want to learn about leadership, from small teams to large organizations, stop wasting time with “business” books, “management” books, consultants and seminars, and instead get (and read) the complete set of C S Forrester’s Horatio Hornblower books. * "Blue Water Software Development" is the working title for my book on these ideas. What do you think?
|
-
John Cleese (yes that John Cleese) tells the story of his "favorite childhood superhero, Gordon the Guided Missle". In each episode, Gordon would be given a task. Setting out to accomplish this task, he would be constantly told how he was wrong: too low, too high, target to the left, target to the right, etc. He was always wrong. Always mistaken. However, he never despaired, and grew more confident with every correction. Finally, at the end of every episode he would reach his target successfully, and everyone was happy. The lesson Cleese wants you to take is that it was because Gordon was willing to be "continually" wrong that he was ultimately successful. Gordon's "Process for Success" depended on feedback. It depended on "tracking the moving target" by constantly changing his direction. Viewed from the larger perspective, Gordon's ability to consistently deliver successful results was more stable because he included feedback and a willingness to admit mistakes. Even more so, an eagerness to make as many small mistakes as quickly as possible before they became big mistakes. The theory behind system stability from feedback goes back to Von Neumann's Cybernetics and the original work on System Theory. Systems that can flex are inherently better than those that are rigid. You can see this in everything from ancient Japanese earthquake-resistant buildings to metabolic mechanisms to eco-systems to market economies. Why should an endeavor as complicated as buiding software be any different? You know you are going to get feedback. Do you unit test? Of course. Why? To feedback the test results into better code. Does your team do regular system builds? Pre-production tests? Beta releases? Customer-reviewed prototypes? Feedback, feedback, feedback, feedback. Grab hold of this live wire. Consciously use this power. But this can be scary. What keeps you from being electrocuted instead? What about the "feedback" when you put the microphone in front of the speaker? Tulip-mania and the dot-com bubble? Haven't you seen the Tacoma Narrows Bridge video (http://www.civeng.carleton.ca/Exhibits/Tacoma_Narrows/)? Won't constant feedback, from customers or users, just as easily lead to cost overruns? Drive the project "into the ditch"? Everytime I talk to customers they add more features! And we have a fixed-price contract for a specific deliverable! As with any tool, feedback can burn your hand or cook your dinner. Software development must use controlled feedback. It will depend on being explicit about the why's and what kinds of feedback you solicit. As I hear the doubts ("so, how do I control this feedback?") I ask you to consider the following "homework" question: What keeps your unit testing from eventually generating an infinite number of bugs? Why doesn't each "fix" create even more bugs? ---- References: John Cleese' quotes from his speech on "The Importance of Mistakes"; any errors or misinterpretations are mine. Padulo and Arbib's "System Theory" was my basic text on linear system theory.
|
-
There are still organizations that claim they do not use an iterative development process. Why is that? Wasn't this argument settled long ago? The so-called non-iterative methods, such as waterfall, are most often used in organizations where the dominating culture is that of Mistake-Avoidance. This can come from a number of sources: don't waste the taxpayer's money, we can't tell the business people we made a mistake, or simply management that has never developed software using modern IDE's. Non-iterative methods are used even in organizations that do not manage by fear. In talking to the IT department of a southeast asian central bank, I discovered they were happy and well adjusted, but insisted they did not use iteration. Projects lasted between 9 to 36 months. Delving deeper, it turned out that, yes, once fielded they did get feedback from users of changes, fixes, and enhancements, and yes, they collected those over a period of 6 or so months, at which point they would often start a new version of the application. My claim was that their iterations were just very, very, long. Short iterations (e.g., daily) are empowered by modern IDE's. Iterative developement is essential for delivery of effective software. Management's avoidance of iteration centers around a fear of chaos and loss of control. "How do you know you are done?", "How do you budget and staff the project?", etc. The analogy I like to use is that of the Sailboat and the Locomotive. Iterative development is captaining a sailboat---a method designed to handle changes in wind direction, currents, crew, revised destination, etc. Non-iterative development is a locomotive, meant to be predictable and repeatable. It is possible that in a restricted domain and problem space that software development could be organized to run like a train schedule. Beware if there is ever a bridge out, though. Software professionals need to think, plan, act and manage more as sailors than conductors.
|
-
An example of a Software Project pattern. [What makes a project successful is Project Leadership, which too often is incarnated as Project Management. What is involved in Leadership that makes a project successful will be covered later.]
Pattern Name: Multi-site Development (AKA “Offshore Development”)
Context: Key development resources are not available in a single geographic location, due to either quality or quantity. Or specific technical or domain skill. One resolution is to move all the required personnel into a single location for the duration of the project. But “the duration“ may be indeterminant. Or there may be a cost differential between development resources in different locations.
Forces: The main forces to be reconciled include:
Total return on investment. That is, getting the project completed for the lowest cost.
Community of Understanding. All levels and locales of development need to know what they should be working on, and how their part fits into the whole (or at least the whole as it is in their location).
Effeciency/predictability. The amount and kind of work that can be accomplished in each location for each appropriate period of time needs to be within a scope of estimation. (“Scope of Estimation“ in the DeMarco sense).
Solution
Resolution of these forces as successful Multi-site Development requires project leadership around at least the following areas:
Resource Usage: Geographic sub-teams own specific deliverables. That is, the distribution of development across geographic boundaries should be tied to the distribution of functionality development responsibility.
Technology/Architecture with at least the following elements. An enterprise architecture articulated to at least cover this project to the extent that clear and precise abstraction barriers are defined. Functional closure behind those barriers. Defined interaction between those functional closures, including processes, techniques and protocols (for example, Service Orientation http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/srorientwp.asp)
Iteration lenth between complete system builds should be “moderate”. That is, often enough that there is at least three iterations before the first major release, but not so many that sub-teams become thrashed.
Formality of manufacture moderately high. Geographic distribution demands externalization of artifacts such as requirements specifications, functionality interaction definitions, architectural guidance, plans, milestones, etc.
Other areas of importance include communication and coordination. Various mechanisms exist to promote communication, which is essential to establishing a community of understanding.
|
-
{since I mention a Microsoft product, I include this disclaimer: “This posting is provided "AS IS" with no warranties, and confers no rights.”}
I use PowerPoint. A lot. As do a lot of people at Microsoft (surprise!). I like the Visio-like picture drawing, and I'm always on the lookout for someone else's clever animations that I can liberate.
PowerPoint has an outline view, where you can see the text of your slides in outline form. It also has a picture view where you can see slide miniatures. Finally there's a slide sorter view where you can see “all” the slides.
What I need is a way to outline at the multiple slide level. For example,
I want to be able to cut/paste, collapse/expand and hide/show entire branches. I want to be able to view a different .ppt as an outline tree during Insert Slides from File. I want to see someone else's hierarchical organization of their material.
In other words, I want an intermediate level of presentation abstraction between single-slide and entire-presentation.
(A nice feature would be something similar to Word's split screen that allows you to see two points in the same document simultaneously.)
Once that is done I would also like a level of abstraction ABOVE the single presentation mode. This would be a multi-presentation “slide sorter” view, that would allow you to compare, contrast, and organize material across slide trees (remember all these presentations are now in the slide outline tree mode described above).
These changes would in and of themselves be worth a 10% to 20% productivity improvement for me.
Now all I need is an easy way to search (by topic, content, picture, animation, etc) the bazillions of slides floating around all the file servers all over this company . . .
|
-
Alex Keizer recommends McConnell's “Rapid Development” for good ideas on software development projects.
Let me back up a bit and explain a bit more of where I would like to go with this.
“Software” has been recognized as an engineering activity for at least 30 years. That is, it was recognized that some “process” was involved in its creation. The first hint I had was Donald E. Knuth's “Art of Computer Programming” {please note the title!}. Since then there have been methodologies, methods, techniques, processes, management schemes, etc that have been proposed, advocated, crusaded, etc.
My conceit is that there can be a “unified field theory”. As with all Pattern literature it is not the patterns themselves that I hope to contribute (as if they weren't in use already they wouldn't be patterns) as it is the thought that this discipline can be so codefied, and that arguments such as “Agile development or Not” can be seen as different solutions (balances) to the set of forces that each project is faced with.
And that by moving up to this level of abstraction will allow the heat and energy now being expended arguing “which is better” can instead be spent creatively on defining the balance point(s) where a particular pattern is useful.
In this theory I would like to limit the number of forces (perhaps better thought of as force categories) and the elements of control (parameters brought into a specific balance in a specific pattern). But I am willing to be convinced that there are more than I have so far enumerated.
As a teaser, some of the pattern force balances that fit this theory include:
- Offshore/Multisite Development
- Agile Development
- Waterfall Development
- Collaborative Development
- Competitive Market Development
Plus others, of course.
|
-
A short introduction to my framework for successful projects, using terminology from the pattern literature. Future posts will expand on these topics.
Definition of “successful“
There are five basic truths that make a successful software project: regardless of what development environment or programming language is used, no matter whether it is managed using an “agile“ or a waterfall process, OO, SOA, AI or punch cards.
They are:
- The customer/user has a reason for the project (based on their need, a demonstrated ROI, “it sounds cool“, etc)
- The developers know what they are building (there is some mechanism for requirements specification)
- The developers know how they are to do it (knowledge and usage of tools and “process“)
- The development team will know when they are done (there exists some “exit“ milestone criteria)
- The customer/user agrees (they accept or purchase it)
My claim is that all software project “failures” can be traced back to a violation of one or more of these.
Forces on software projects
There are a number of “forces” on a software project.
These include (but are not limited to):
- Level of business/customer satisfaction—functionality, usability
- Time-to-market—deadlines, milestones, marketplace, competition
- Development team self sufficiency—technology/knowledge, resources
- Expected return on investment (and timeframe)—value, tangible, intangible
- Developer's community of understanding—shared knowledge, sharing mechanism
- Need for efficiency and predictability—estimate accuracy, resource usage
- Development organization's culture—risk tolerance, “learning” organization
Control
Finally there are various elements that the development team can control. They include:
- Development technology/tool (team's familiarity with, effectiveness of, appropriateness for solution)
- Technical support for technology/tool (mentors, training, collaboration)
- Team size/composition and geographical locality (includes skill sets, team organization, and management)
- Iteration length (of any defined milestone, e.g., including release schedule; for continuous hacking, Length = 0, for waterfall, Length = Infinite (or “all of it“, there is no iteration)
- Formality (artifacts, models, documentation, process mechanisms)
I propose that:
- Software development must balance the forces using the control mechanisms
- There are a number of patterns that “solve“ the balance
- Different tools and technologies can make this easier or harder
- A particular “balance point“ for a given project may “move“ in the force space as the project progresses
- Different tools and technologies can help or hinder balance control
|
|
|
|
