YAGNI… one of the most important concepts

In software engineering, YAGNI, short for ‘You Aren’t Gonna Need It’, suggests to programmers that they should not add functionality until it is necessary. Ron Jeffries writes, “Always implement things when you actually need them, never when you just foresee that you need them.” According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

  • The time spent is taken from adding, testing or improving necessary functionality.
  • The new features must be debugged, documented, and supported.
  • Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
  • Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
    It leads to code bloat; the software becomes larger and more complicated.
  • Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
  • Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

The above excerpt is taken from today’s Wikipedia entry… Check it out…


Clone Detective for Visual Studio

Clone Detective is a Visual Studio integration that allows you to analyze C# projects for source code that is duplicated somewhere else. Having duplicates can easily lead to inconsistencies and often is an indicator for poorly factored code.

Check it out…


It’s based on ConQAT…

ConQAT (Continuous Quality Assessment Toolkit) is a toolkit for the efficient creation of control centers for the continuous controlling of software quality. Its composition mechanism enables the integration of various quality assessment tools in a flexible manner. ConQAT is not limited to the analysis of source code but can be extended to work on other kinds of development artefacts. It provides tailorable aggregation mechanisms that support the condensation of quality data to generate concise quality reports. These aggregations and ConQAT’s visualization mechanisms are built to enable developers and project managers to track key quality aspects of software projects in an efficient and timely manner.

Check it out…


Seeing that Flex projects get bigger and bigger, teams get bigger and bigger and hence the codebase gets bigger as well, we need tools like this in the ActionScript coding toolsuite… When I get 5 minutes of sparetime, I will look into what it would take to make minor implementation of the duplicate code checker for ActionScript… it should be not too difficult (remembering the beauty of simplicity which I definitely learned the hard way during my first compiler implementation when I was back at University)


Estimation : Off-The-Cuff Estimates

Project teams are sometimes trapped by off-the-cuff estimates.

A projectmanager on a team asks, for example, “How long would it take to implement this component”, while showing the developer a wireframe. The immediate response is typically, “I don’t know. I think it might take a week. I’ll check into it”, and of the developer is to his/her desk to investigate the functional requirements further. Back at the desk the developer looks at the design and code for the component, back at the desk the developer notices a few things forgotten when the PM asked the question, adds up the changes and decides that it would take about 3 weeks. The developer hurry over to the PM’s desk to update the first estimate, but the PM is in a meeting and therefore not to be found. Later that day the PM suddenly appear at the developer’s desk and happily notifies the developer (before this can get a word out): “Since it seemed like a small project, I went ahead and talked to the customer about it. He was very excited about it and can’t wait to see the component next week. Can your start working on it today?”.

I have found that the safest policy is NOT to give off-the-cuff estimates. Using intuition and guessing as basis of software estimates are almost always related with cost and schedule overruns.

One of the errors people commit when estimating solely from personal memory is that they compare the new project to their memory of how long a past project took, or how much effort is required. Unfortunately peoples sometimes remember their estimate for the past project rather than the actual outcome of the past project. If they use their past estimate as the basis for a new estimate, and the past project’s actual outcome was that it overran its estimate, guess what? The estimator has just calibrated a project overrun into the estimate for the new project.

While guessing and intuition most definitely are positively correlated with project overruns, another less recognized fact is that the use of documented facts are negatively correlated with project overruns. In other words, there is a world of difference between giving the PM an off-the-cuff estimate versus saying, “I can’t give you an answer of the top of my head, but let me go back to my desk, check a few notes, and get back to you in 15 minutes. Would that be OK?”.

While this is a simple point, off-the-cuff estimates is one of the most common errors that project teams make. So in order to become a better software engineer, we need to stop delivering off-the-cuff estimates !

This blog post is the first in a long series about estimation I will be doing. Estimation is probably the single most important skill next to actual programmatic skills for a programmer, and even for non-programmers estimation is one of the most frequently performed activities, however also one of the skills that we pay the least attention to.

First step in becoming a better estimator is to realize that off-the-cuff estimates are invalid and errorprone, and should be replaced by a structured analysis of the entity being estimated based on documented facts.


Writing Final Classes and Methods

Final Classes
You can declare that your class is final; that is, that your class cannot be subclassed. There are (at least) two reasons why you might want to do this: security reasons and design reasons.

One mechanism that hackers use to subvert systems is to create subclasses of a class and then substitute their class for the original. The subclass looks and feels like the original class but does vastly different things possibly causing damage or getting into private information. To prevent this kind of subversion, you can declare your class to be final and prevent any subclasses from being created. The String class is a final class for just this reason. The String class is so vital to the operation of the compiler and the interpreter that the system must guarantee that whenever a method or object uses a String they get exactly a String and not some other string. This ensures that all strings have no strange, inconsistent, undesirable, or unpredictable properties.

If you try to compile a subclass of a final class, the compiler will print an error message and refuse to compile your program. In addition, the bytecode verifier ensures that the subversion is not taking place at the bytecode level by checking to make sure that a class is not a subclass of a final class.

Another reason you may wish to declare a class as final are for object-oriented design reasons. You may think that your class is “perfect” or that, conceptually, your class should have no subclasses.

To specify that your class is a final class, use the keyword final before the class keyword in your class declaration. For example, if you wanted to declare your (perfect) EncryptionAlogrithm class as final, its declaration would look like this:

final class EncryptionAlogrithm
. . .

Any subsequent attempts to subclass EncryptionAlogrithm will result in a compiler error.

Final Methods
If creating a final class seems heavy handed for your needs, and you really just want to protect some of your class’s methods from being overridden, you can use the final keyword in a method declaration to indicate to the compiler that the method cannot be overridden by subclasses.

You might wish to make a method final if the method has an implementation that should not be changed and is critical to the consistent state of the object. For example, instead of making your EncryptionAlogrithm class final, you might just want to make the decrypt method final:

class EncryptionAlogrithm
. . .
final void encrypt( message:IMessage )
. . .
. . .