|
|
|
Jeff Sutherland's Object Technology Web Site
Innovate faster. Eat your competitor's lunch!
Communicate benefits clearly. Get more resources!
Design systems better. Make your stuff really work!
Build agile systems. Deliver faster, better, cheaper!
Deploy quality systems. Capture customer loyalty!
|
|
| |
Sunday, October 06, 2002
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.
1:34 PM
Monday, September 30, 2002
Morning Roll Call: Issue 101
"During my days running professional engineering services for a Department of Defense consultancy, we used daily "stand-up" meetings during the (harried) proposal preparation process. Here, the idea was to make the meetings as brief as possible (hence the standup part -- no getting comfortable in a big chair). The meetings were designed to quickly keep everyone informed of progress, to highlight any problems, and to provide cross-team collaboration.
"As you'll see from reading David's article (and references on SCRUM), these types of meetings can have very beneficial effects on a development project."
--Jon Kern
3:03 AM
Thursday, September 26, 2002
Agile Software Development Methods: Review and Analysis
Abrahasson, Pekka et al. Agile software development: Review and Analysis. ESPOO 2002, VTT Publications 478. 107p.
Keywords: Software development, agile processes, agile methods, extreme programming, agile modelling, open source software development, software project management
Abstract: Agile--denoting "the quality of being agile; readiness for motion, nimbleness, activity, dexterity in motion"--software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler sofware development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment. The new agile methods have evoked a substantial amount of literature and debates. However, academic research on the subject is still scarce, as most of existing publications are written by practitioners or consultants.
The aim of this publication is to begin filling this gap by systematically reviewing the existing literature on agile sofware development methodologies. This publication has three purposes. First, it proposes a definition and a classification of agile software development approaches. Second, it analyses ten sotware development methods that can be characterized as being "agile" against the defined criteria. Third, it compares these methods and highlights their similarities and differences. Based on this analysis, future research needs are identified and discussed.
3:39 PM
Sunday, September 22, 2002
Agile User Groups
There are user groups springing up around the Agile Alliance focused on improving development processes along the lines of the Agile Manifesto. I attended the New England Agile User Group on Thursday, 18 September, and a good time was had by all. Ken Schwaber's comments provide a summary of the meeting.
There is also a new user group in Calgary: Calgary Agile Methods User Group (CAMUG)
3:14 PM
Friday, August 23, 2002
How Stuff Works: Wireless Security Blackpaper
Where do you go to get a good description of how wireless security works, how it gets hacked, and how to prevent intrusion? You can go to vendor sites and weed through the hype, or to hacker sites and sort through dense technical detail. Maybe you just need a good technical description. Trey "Azariah" Dismukes has written a Wireless Security Blackpaper that fits the bill.
"While wireless networks have seen widespread adoption in the home user markets, widely reported and easily exploited holes in the standard security system have stunted wireless' deployment rate in enterprise environments. While many people don't know exactly what the weaknesses are, most have accepted the prevailing wisdom that wireless networks are inherently insecure and nothing can be done about it. Can wireless networks be deployed securely today? What exactly are the security holes in the current standard, and how do they work? Where is wireless security headed in the future? This article attempts to shed light on these questions and others about wireless networking security in an enterprise environment."
11:00 AM
Wednesday, August 21, 2002
SCRUM vs. Waterfall: Point and Counterpoint
Note: CMM is a service mark of the Software Engineering Institute at Carnegie Mellon University.
Shawn Presson, Director of Organizational Practice, ITS Services, Inc. says:
Why, why, why does everything think the waterfall life cycle is exclusively linear? It was designed to be extremely iterative, it allowed for the fact that there may be parallel, non-sequential sets of requirements under development (hence multiple, simultaneous "waterfalls"), it in no way assumed that requirements will be static during a project. It was only after the DoD got its hands on it that this interpretation of the model came about, but why are we listening to the DoD on something like this? ...
Why, why, why do we assume that "repeatable" and "defined" models preclude emergence? These terms are obvious reference to the CMMs, but the CMMs don't lock you into waterfall, spiral, or any other life cycle or methodology. With reference to requirements, the CMM says, "don't let your junior developer bet the farm on meeting a requirement that the project doesn't know about." Does SCRUM cover this point? Great, then SCRUM is the METHOD whereby this important principle (NOT "process") contained in the model is carried out...SCRUM (or JAD, or whatever) is the METHOD whereby your company avoids inadvertently lying about its capabilities (which is what the CMM planning is largely about, anyway.)... (See full text)
Ken Schwaber of the Agile Alliance responds:
Reading Shawn Presson’s comments regarding CMM, waterfall, and agile reminded me of Barry Boehm’s comments at XP/Agile Universe’02 and the comments of several CMM authors at INCOSE’02. I was reminded of the good intentions and sound footings of CMM and Waterfall, both initiated to address problems in systems development and systemic project failures rates that have only marginally improved over the decades...
...CMM, waterfall spring from a different theoretical basis than agile processes. Increased precision and definition are at their core, which is one of the alternatives for controlling a process. However, this approach only works when the definition and the problem have a mapping approaching 1:1 and the problem domain (technical, requirements, and people) is relatively simple: “It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.” Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992.
The agile process is based on the empirical approach, accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation...Empiricism is seen even in the Agile Manifesto, where the signatories pose agility as an empirical counterpoint to a defined approach, rather than as a new set of defined absolutes. The various agile processes implement empiricism with the underlying practices of iterative development, frequent inspection of status and increments of work, self-organizing teams, emerging architecture and requirements, and solid collaboration... (See full text)
5:23 PM
Tuesday, July 30, 2002
Architecture:
Ratio Group Ltd. has some interesting papers in its technical library. I was recently reviewing:
Collins-Cope, Mark and Matthews, Hubert. A Reference Architecture for Component Based Development. Ratio Group Ltd.
The paper propose a reference architecture for objet=oriented/component based systems consisting of five layers... More specific (and therefore less reusable) components are placed in the higher layers, and the more general, reusable components are in the lower layers. Since general non-application components are less likely to change than application specific ones, this leads to a stable system as all dependencies are downward in the direction of stability, and so changes tend not to propagate across the system as a whole.
In general, systems implementation I have reviewed do not do a great job of eliminating dependencies across components so this paper is worth reading by all developers. There are deeper issues of unavoidable dependencies across well implemented components that merit serious analysis. I'm currently writing a paper on this which will be a sequel to a forthcoming Communciations of the ACM publication:
Sutherland, Jeff
5:58 PM
|
|
| |
|
|
|
Stuff technical leaders need to know. On the web since 1995.
