Yagni And Logging

ExtremeProgramming argues that you don't add functionality until you need it: This is called YouArentGonnaNeedIt, or Yagni for short. Can you apply this principle even to logging?

I suspect the reason why "an XP guru" might state that "you don't add logging to a project until you know you need it" is that we commonly use logging, a.k.a. instrumenting the program, as a debugging aid, and XP practitioners believe that UnitTests are a more effective tool to ensure software quality.

Then they haven't tried to debug a large system that has been up for a while. For that you need logging.

There is an interesting confusion between logging and instrumenting here. Before I started using UnitTests, my code used to contain lot of stuff like :

    System.err.println(new Date() + " - SomeClass.java - " + thingumabog.toString());

That's instrumenting -- your code contains code that does nothing but record a very narrow "view" of how your program executes. This is usually so you can catch bugs, by looking at the output of the program after a failed run and scanning for entries that make no sense.

I've found that UnitTests let me dispense with instrumenting. The assert() calls in my unit tests do exactly what I used to do manually to instrumentation entries - compare method results to expected results. I still instrument from time to time - when I do, I only instrument my unit tests, though; they have become the best place to reproduce tricky situations that I previously could only catch with "monkey testing" techniques, even with code instrumentation. Another reason for instrumenting is performance measurements. I have found that using "real" profiling tools (e.g. http://www.optimizeit.com/) is a far better alternative.

Logging is something you'd use when you have other reasons to know what your code has been doing - e.g. which users use which parts of the system, how much this or that part of the system is being used or abused, or so you can "roll back" part of what the system did a la transactional processing.

It's a bit hard to imagine an engineer needing the above without it being an explicit functional requirement. Even if she anticipates being required to implement such a system, wouldn't it be safe to just ask the customer for her opinion - rather than take it upon herself to actually implement it?

I personally believe that there is an middle ground between YouArentGonnaNeedIt and YouAreGonnaNeedIt that hasn't properly been explored. My personal rule of thumb runs more along the lines of youUsuallyArentGonnaNeedIt, which does allow for some speculation about future needs (logging being an excellent example, in my opinion). I'm also a subscriber to the well known KissPrinciple, which can be seen as a less extreme form of DoTheSimplestThingThatCouldPossiblyWork. My main point is that cool as XP is, it really suffers from, well, being too extreme. But then I've said this before -- see TurnAllTheKnobsToSeven. -- CurtisBartley

Tried to find the right place to insert this but couldn't.

Why do you want logging?

 To improve delivery times (debugging aid)
 To improve fault finding (maintenance aid)
 For users to track business level issues (auditing)

Assuming the code will take significant (more than half an ideal day) effort to add, then it should be presented to the customer to see if they are willing to pay for it.

The first two reasons can be presented as construction cost/benefit so the customer can see how it will affect the project delivery schedule. If they agree to the spend based on the analysis then you allocate the time and do it.

The last is truly a UserStory and should be treated as such. There is nothing in XP to say that an experienced developer is forbidden from suggesting to a group of traders (for example) that in the developer's experience the Operations, Compliance and Technical Support desks would value an auditing (logging) function and perhaps should be consulted about it.

Again there is nothing in XP that forbids arguing strenuously with the customer to put a feature in. At the end of the discussion it is their money and, if you have failed to convince them then you should not do it. -- TomAyerst

Why do you want logging?

Well, unless you are a soothsayer, you will not know how the project will transition. However, you have written enough system to generalize the behavior of logging so that it is extensible and customizable. Furthermore, because of your expertise, you can do it in approximately the same amount of time (~4 hours) it would take to do a specialized one. It always (in the long run) takes less time to do something right. So you understand the generalization sometimes takes more lead time but will save time and quality in the end. The arguments against reuse, frameworks, and infrastructures seems another area where XP is too extreme.

significant (more than half an ideal day)

If XP allows one to schedule individual, granular tasks with plus or minus half a day degree of accuracy then it is a SilverBullet and I would need a lot of proof to accept that. This assumes that design and development are done with tools that allow us to work quantifiably. We just don't have that, hence the old-school algorithm of n = (n * 2) + (n / 2) for estimating time.

...then it should be presented to the customer...

Here, I'm assuming the customer is those ProjectStakeholders you are working with to set the functional requirements and it is not the GoldOwner? I don't think the above statements are accurate. The customer is your domain expert, it is the GoldOwner (or whoever dictates the ship date requirements) that you should be talking about scheduling issues with. Furthermore, I have a hard time with the idea that the customer or schedule-owner needs to be an expert on the ideas of reuse or increasing returns in design and development. These ProjectStakeholders may have no clue about the benefits of generalizing the logging package and may not understand if you explain. They are not aware of the forces that cause an engineer to generalize instead of specialize. We may be aware that there are 3 requirements that could fall under the umbrella of logging. Furthermore, we know that (a) requirements will change and that (b) this isn't the last version of the product. We shouldn't expect every ProjectStakeholder to understand all the analysis and design implications of this.

On large or commercial systems, there are often many and different kinds of ProjectStakeholders that have input into the requirements. Do we get down to the task level with each? I guess I don't know. If everything I've heard on this page is true (and I'm not sure it is), I am lead to believe that XP does not recognize the many ProjectStakeholders that have different kinds of interests (and areas of expertise) who own a piece of the functional and non-functional requirements or quality attributes. It almost sounds like XP replaces BigDesignUpFront with BigPlanningUpFront?. Given how much requirements change, I'm not sure how good of an investment that is. Clearly we need hour (half-hour is pushing it) granularity estimates for the Tasks in the opportunistic WorkQueue for each EVO. However, these EngineeringTasks may not always have a 1 to 1 cardinality with UserStories and there for just aggregate into the complete UserStory (or UseCase) estimate.

Of course, I'll admit that I'm not fond of any one methodology (or the idea of self-contained methodologies). I believe that software is too chaotic to formalize (even as much as XP attempts to) into a rigid structure. As architects, project managers, engineers, and so on we have a large bag of BestPractices available to us and different projects require different combinations of these idioms and methods. --RobertDiFalco

I have altered 4 ideal hours to 1/2 ideal day, which is what I meant, I hope you don't mind. I feel, however that I was wrong about the level of granularity. I still feel the principal is correct but you are quite correct about the estimation granularity issue (at least at the story level).

You do not (cannot) get the customer(s) involved in detailed design decisions but you do have to present them with options based on your knowledge and allow them to decide how to spend their money.

I have found in my experience that my users have trusted me, and accepted my recommendation on issues like this.

I just realized another possible reason for the conflict. For some projects, logging could be considered as basic and essential as simple collection structures. While one could rewrite this code for individual projects, there are several advantages of a widely-used standard library. (Java, C++, and most Smalltalk versions have large standard libraries.) The Java logging example above is the kind of code one might put in a local-standard library used by multiple projects. --CliffordAdams

Why do we compare software developers with automobile mechanics? Aren't automobile manufacturers a better choice? --NikitaBelenki

Probably because most software development is maintenance work - correcting (debugging), perfecting (the optimising you do after you get it working, such as get it fast, get the code readable, remove duplication) - or at best adaptation of the existing codebase to meet changed needs. That is, we're trying to put a new frammistat into the user's car, not designing the new WhizzoCar? that will be launched in 5 years time. --GordonLove

There are two ways of looking at logging: debug logging and customer logging. Debug logging provides information that the development team uses in development, and is meant for nobody else.

Debug logging should be non-negotiable, like refactoring. It should also be flagged off before external release.

I don't see this. Debug logging shouldn't be required - that's what a clear, refactored design and sensible use of exceptions gives you. -- TorneWuff

Customer logging is used by people that the customer represents, whether those people are end customers, professional auditors, or your tech support squad. This sort of logging is a UserStory, and thus in the hands of the customer.

In the frequent case where the development team will double as the tech support squad, it is perfectly within reason to approach the customer from his side of the table, like any other stakeholder, and tell him the business benefits of logging (fewer untraceable errors, money saved on the tech support line, customers being able to debug their own stuff, etc.). When you do this, take off your programmer hat and put on your user hat--a tech support rep is a bona fide user of the software, after all.

However, if you're writing a commercial product, framework, or systems development, you may have dedicated support professionals. They're your users, too. Keep in mind that the support people may work for your company, not the client, so in normal conversation with the client the support people's needs will simply not come up.

(This may be where XP betrays its origins in internal or vertical-market applications, since the thinking on requirements doesn't deal so explicitly with balancing the needs of distinct groups of users.)

Contributors: CurtisBartley, RobertDiFalco, RobMandeville, ChrisSteinbach

External fault finding is probably the most important use for logging. It's essential for cases where you can't control everything your software might interact with. Structurally my log objects look like database transaction records--they contain data collected and decisions made as some task is performed, often with sufficient completeness that they can be used to simulate the operation later. If the task is ultimately successful, the log is marked for erasure (but we defer the actual erasure as much as possible, in case we might later learn that we were not as successful as we thought we were). If the task is not successful, then we move the log to stable storage and examine it to find out why. --ZygoBlaxell

It seems to me that the need for logging comes from an indirect user requirement. This requirement is one that is often overlooked by user but is often implied. This requirement goes something like this. "When the system you are building me breaks, I want tools to fix it in X number of diagnostic steps." This is where good logging pays off and yes we can express the need as a user story. It's very similar to the user story that a car owner would give. "When my tire breaks (explode, etc.. ) there should be tools to repair it in X steps." Sadly, these things are often overlooked because customers don't focus on what should happen when things go wrong. Since we are building software and not airplanes, there is no government agency that requires us to install a black box in our software. However, I think most customers appreciate a predictable system. After all that’s why we write unit tests right? So it stands to reason that, predictability in the face of failure is something a user would desire. To provide predictability in the face of failure, logging deserves a user story. --ChristopherGrow?

Examples for discussion: ExampleLoggingFramework, OneRealWorldLoggingSystem

See YagniAndFrameworks, ElicitingRequirements