Darrell Norton's Blog [MVP]

August 2004 - Posts

• Agile Project Management: Principles of Product Delivery

  This is part 2 of a 10-part series I am writing on Agile Project Management, by Jim Highsmith. Like most methodologies, agile and otherwise, Agile Project Management has some foundational principles. The six principles are divided into two groups of three. One group is focused on product delivery, while the other deals with management. Today I will explain in detail the principles grouped under Product Delivery: Deliver customer value Employ iterative feature delivery Champion technical excellence Delivering customer value puts the focus back where it belongs, on building working software. Too many process-heavy organizations seem to think that completing process documentation means progress is being made (I’ve been there and it isn’t pretty). By making this a core principle, process documentation and other “compliance” activities are properly seen as wasted effort to be minimized (see my Lean Software Development Overview). Employing iterative feature delivery is based on two fundamental software development facts. The first is that iterative development is all but required for any non-trivial software project (see Agile and Iterative Development). The second is that feature-based development results in tangible progress that the customer can interact with, improving the feedback back to the development team. Finally, championing technical excellence keeps quality high. High-quality software includes many factors other than defects, such as reliability, stability, scalability, performance, adaptability to future needs, etc. (see Facts and Fallacies of Software Engineering). These facets of quality, expressed through technical excellence, deliver customer value throughout the application’s lifetime. Posted Aug 31 2004, 06:41 AM by darrell with no comments

• Agile Project Management: Why?

  This is part 1 of a 10-part series I am writing on Agile Project Management, by Jim Highsmith. The first question to ask is, “Why should I consider using Agile Project Management?” Time-to-market has shrunk. A lot of it had to do with “Internet-time”, but even after the bubble burst our schedules did not expand again. I have found unrealistic schedules to be the norm, with the occasional fantasy schedule thrown in for variety. Customers rule. Customers are pickier than ever, and if you don’t have what they want, someone else will. There are too many competitors willing to fill a market need, so we can never become complacent in our offerings. These factors combine to force the hand of anticipatory project management, the kind that “plans the work and works the plan.” But if the market is changing rapidly, then the plans set in stone 6 months ago really are outdated. One response is to develop products incrementally, focusing on adding the most value first. This practice, known as iterative development, leads to software that evolves into a killer application instead of trying to design and implement one on first pass. Agile Project Management (APM) recognizes that opportunity and risk lie in the software, not in the project management approach. So APM attempts to mitigate risk and maximize opportunity in order to meet the business objective of Reliable Innovation, which consists of five parts: continuous innovation, software adaptability, reduced delivery schedules, people and process adaptability, and reliable results. It attempts to deliver reliable innovation through its principles and framework (in tomorrow’s post!). Posted Aug 30 2004, 02:59 PM by darrell with 3 comment(s)

• Scalability and high availability guidance for BizTalk Server 2004

  Finally some guidance on scalability! A new BizTalk Server 2004 download: Scalability and High Availability in BizTalk Server 2004 The architectural components of BizTalk Server 2004 that facilitate scalability and high-availability are based on robust methodologies and mechanisms embedded and integrated within BizTalk Server, SQL Server and Windows Server 2003. This multi-faceted scalability and high-availability architecture provides numerous options for designing OSS/BSS integration applications that can be expanded to meet any performance and growth contingencies on an incremental or exponential basis without any operational disruption. Posted Aug 30 2004, 07:07 AM by darrell with no comments

• Eric Sink starts a series on Source Control

  Eric Sink is starting a new series of posts on Souce Control. He’s got 3 chapters up so far. Posted Aug 27 2004, 05:26 AM by darrell with no comments

• Firefox tweak program built in .NET

  Check out this cool product in Beta, FireTweaker XP. It’s customizes Firefox and it’s built using .NET! FireTweaker XP requires Microsoft .NET Framework 1.1 and a clean installation of Mozilla Firefox 0.9.x to run properly. Please keep in mind that only the Official version of Firefox, which is released on Mozilla.org and available for download, is supported by Firetweaker! Any other custom compiled versions of Firefox will not be tweaked and may cause Firetweaker to crash or generate errors. FireTweaker XP Includes: Appearance: 9 Tweaks to change the Appearance of your browser. Performance: 4 Tweaks to increase the performance of your browser, [NEW] Including the Firefox Auto-Optimizer which will automatically optimize your page-loading and rendering performance. [NEW] Behavior: 9 Tweaks to change the Behavior of your browser. Webpage Appearance: 6 Tweaks to customize the way you'd like firefox to render webpages. RollBack!: Easily rollback all applied tweaks with the click of a button! Posted Aug 26 2004, 07:28 PM by darrell with 7 comment(s)

• Announcing the Agile Project Management series

  I just finished reading Agile Project Management by Jim Highsmith last night. Instead of the normal book review style, I wanted to try something a little different (inspired by Eric Sink’s 22 Laws of Marketing series). Starting Monday, August 30, I will be posting a summary of each chapter interspersed with my thoughts. I guess I’ll call this the “Agile Project Management series.” This is not meant to replace the book in any way; in fact I have purposely been vague enough not to give too much away. My personal goal was to see if writing up a short summary of each chapter would change the way I internalized the information. You will have to let me know if you like the format, if I am presenting valuable information, and/or getting you thinking about Agile Project Management. Posted Aug 26 2004, 11:45 AM by darrell with no comments

• Proper exception handling

  I’m going to throw my two cents into the exception discussion that Brendan brought up. I believe Jeffrey Richter's approach is the best, which I learned in person at Devscovery (the “low level” sessions like this were the best ones in the conference). The East Bay IT Group (ebig) has a great overview of Jeff’s exception talk, shown here in part: “Jeffrey began his talk by defining an exception as an event that occurs when an implicit assumption is violated, and not as many people erroneously believe, simply a rarely occurring event. When an implicit assumption is violated, an exception event should be generated rather than having the function return an error code. Jeffrey gave a great example of how the legacy tradition of returning a -1 for a file read function at the end of a file is actually improper and how it can cause coding difficulties and application errors. Richter presented an impressive list of the benefits of exception handling. By using more robust, maintainable object oriented code, the result is cleaner, uncluttered centralized program logic. One of the unexpected benefits of exception handling is better performance because many errors can be processed centrally instead of after each function call. Although some early implementations of exception handling using C++ had poor performance, the efficiency of Microsoft’s .NET garbage collector has all but eliminated these problems. Jeffrey ended his talk with guidelines and best practices for exception handling including liberal use of finally blocks, catching specific exceptions (only lazy developers catch all), graceful recovery design pattern, and backing out but not swallowing of exceptions. In his presentation on exception handling, Jeffrey did more than describe the rules and show code examples for exception handling on .NET (which, of course, he did exceptionally well). He described a common sense way of looking at exceptions that everyone in the audience could understand. Jeffrey said that an exception occurs when an implicit assumption is violated, and not, as many people erroneously believe, when a rare event has occurred. Richter ended his talk on a positive note, demonstrating that proper handling of exceptions produces cleaner, less cluttered code that is easy to understand and is highly performant.” [ebig newsletter] Posted Aug 25 2004, 12:05 PM by darrell with 15 comment(s)

• Microsoft launches new BizTalk developer center

  Microsoft just launched the new Business Process and Integration Developer center, which covers mostly BizTalk. There’s even a new monthly column. Posted Aug 24 2004, 05:35 AM by darrell with no comments

• Thanks Jim Newkirk

  Jim Newkirk has selected my suggestion for a new Test Driven Development example, the bookmark collection. Jim will be posting the first task for the new example and the related tests this week. I’ll definitely be reading! Posted Aug 23 2004, 02:03 PM by darrell with 2 comment(s)

• 7 simple ways to add a little agile

  StickyMinds has a good public article available right now called Traditional – with a Twist: 7 Simple Ways to Add a Little Agile without Going to Extremes by Peter Schuh. Here’s the intr “Are you in the midst of a traditional development project that cannot take a leap toward Agile, but you know could benefit from being nudged in that direction? Does your project have stakeholders or management who are willing to discuss the merits of Agile development but won’t give you the time to investigate an Agile methodology, much less switch to it? Are you a project manager or team lead who has read or heard a bit about Agile development and wants to experiment with it but are, yourself, too skeptical to make a large upfront investment?” It’s a good read on basic agile practices that you can do on any project without needing management permission (except for the one about the user). It’s a good list to get started with. Posted Aug 20 2004, 11:28 AM by darrell with 6 comment(s)

• CIO Magazine devotes an entire issue to Agile IT

  I recently got my CIO magazine and the entire issue is devoted to Agile IT! There is a list of the top 100 agile IT companies, an article about the Department of Defense’s moves toward agility, how to build an agile IT department, and a lot more. A lot of this is at a pretty high level, so don’t expect to see detailed discussions on the technical merits of extreme programming, but it is definitely a good read about higher-level IT issues. And the more you know about those, the more effective you will be at work. Posted Aug 19 2004, 06:49 AM by darrell with 2 comment(s)

• Unit testing a singleton

  Jonathan de Halleux shows the simple way to test a singleton. Given this sample code: using System; public sealed class Singleton {    ...    private Singleton() {}    public static Singleton Instance    {       get { ...}    } } You can test it with reflection like this: using System.Reflection;  [TestFixture] public class SingletonTest {     private Singleton target = null;     [SetUp]     public void SetUp()     {         ConstructorInfo ci =             typeof(Singleton).GetConstructor(                 BindingFlags.Instance |                 BindingFlags.NonPublic,                 null,                 Type.EmptyTypes,                 null                 );          Assert.IsNotNull(ci);          this.target = (Singleton)ci.Invoke(null);     } } Posted Aug 18 2004, 06:28 AM by darrell with no comments

• Humorous list on Amazon

  This is the top ListMania! list on Amazon right now: So you're going to jail... by Shawn Kresal, Citizen Definitely read his comments! Posted Aug 17 2004, 01:02 PM by darrell with no comments

• How would you implement null argument checking

  Eric Gunnerson wants to know how we would like to avoid Null Argument exceptions. I see this as related to Design-By-Contract. DBC has 3 checks: preconditions, postconditions, and invariants (both pre and post), so only 2 checks are needed and a mechanism to signify both to run. The Null Argument check is a precondition, or maybe an invariant. How is that related to AOP? Well, pre and postconditions are just code interception in one of the simpler models proposed by AOP proponents; messing with code at the beginning and end of the method is the very minimal AOP implementation. Many are more grandiose than that, being able to change code throughout the running of the method (or class, etc.). So perhaps the deeper question is how should C# support AOP, if at all? I'm not prepared to answer that. :) A more pragmatic answer to Eric's question is what is the purpose of checking for null? I usually see it as a "developer exception", in that the developer accidentally sent you a null object when they were developing the application. In this case a NonNull attribute would be fine. How should this behave in a production environment? I would say the same. In fact, this implementation gives the developer metadata to check, versus just looking at the documentation or trial and error. So I'm all for the simplicity of an attribute! Posted Aug 17 2004, 07:03 AM by darrell with no comments

• Where is the compelling argument for software factories?

  Steve Maine blogs about the case for software factories. He uses Timbuk2 as an example of what software factories could be like. What Steve is talking about with Timbuk2 is known as "assemble-to-order" in Operations Management. It's the same thing that Dell does. The vast majority of the manufacturing work is already done, and is just put together as the final product. A bonus is there is much less inventory to hold, as you don't have to hold safety stock for each and every model, just safety stock for each subassembly. Some simple statistical analysis will show that the safety stock needed for this situation is roughly half (or less!) that needed for all the products if stocked in final form. Not to mention the benefits of a pull demand model versus a push one. The customer ordering a computer and Dell building to that order is a pull model, whereas HP sending out a bunch of computers to CompUSA and then trying to sell those computers to customers is a push model. How does that relate to software factories? Well, if you can assemble your software from pre-manufactured subassemblies, then great! I highly recommend using pre-built and pre-tested code whenever possible! However, I think that software should solve new and interesting problems, which kind of negates the whole advantage of software factories. Now if you have an operation like Scott Hanselman does at Corillian, that's an excellent example of a software factory. But notice how narrow the market is for the apps they sell! Yes they customize the UI, but Scott has blogged on numerous occasions on how they generate a large majority of code at the beginning of a project (order really, the flow model again). I think software factories may be applicable to narrow vertical market applications. But then, why not just make the application configurable instead of assembling it to order? Microsoft has proven that mass-market software works, and it is highly profitable. Posted Aug 17 2004, 06:47 AM by darrell with 5 comment(s)