InfoQ article on what it really means to refactor or rewrite. Good read:

http://www.infoq.com/news/2009/11/refactor-rewrite

This week I decided to give you, my dear readers, a little rest from my blabbering and go technical a bit. I am going to talk about a very powerful and a personal favorite NetBeans feature: Refactoring.

If you do not know NetBeans, it is a free, cross-platform, open-source Integrated Development Environment (IDE) for software developers and a product of Sun Microsystems. An IDE is a software application that provides extensive facilities to programmers for software development, such as a source code editor, a compiler, an interpreter, build automation tools, and a debugger. For more information about NetBeans’ features, visit the official website.

Refactoring is about changing your source code easily. Imagine moving a class between packages and having to edit the package statements manually at the top of each file, or wanting delete a variable in the code and not knowing if it is referenced somewhere else in your application. Performing these types of operations manually can be time consuming and prone to error. However, with the advanced refactoring capability available in NetBeans, you can do such changes very easily. NetBeans provides many refactoring options on its Refactor menu. I am going illustrate half of them today and the other half in a following post.

For this post I have created two classes, ImportingClass and MoveClass. View them here and here.

There are some images that are not very clear because of page size limitations. You can click on any image to see it in full size.

Rename:

Rename refactoring allows you to change not only the name of the class but also any constructors, internal usages, and references to the renamed class by other classes. You can also rename the package, which will automatically rename all instances of the package name in your code, including comments. Here, I am going to change the name of the variable value to AddedValue in class ImportingClass:

Automatically, the variable name is also changed in class MoveClass:

Move:

Moving a class from one package to another may seem like an easy task; you just have to copy and paste the contents of the source file into the new directory and then edit the package statement at the top of the file then you are good to go. However, if other classes import or reference that class, then the developer must also search through and modify those files. Here is how you can move MoveClass from the refactoringpackage2 package to refactoringpackage1:

Copy:

Copy refactoring allows you to copy the contents of a class to another package, automatically changing the package statement at the top of the source file.

Safe Delete:

Sometimes when you are reviewing a previously written code, you decide to remove a class member variable that you think is not used, only to find out that it does indeed appear in your code, and then your class does not compile. With Safe Delete refactoring, you can identify each usage of a class, method, or field in code before deleting it. I am going to illustrate it by trying to delete the AddedValue variable from class ImportingClass:

However, the variable was referenced in class MoveClass, so deleting it would cause an error. T=NetBeans alerts you to that, and can even show you where the member you want to delete is referenced if you clicked the “Show Usages…” button:

Change Method Parameters:

Change Method Parameters allows you to safely change everything in a method header- access modifier and arguments- and notifies you if this change is going to affect your source file. Here, I am going to try to delete the parameter x of the display method of class ImportingClass:

Parameter x is used within the method body, and so a warning is displayed:

For the following examples, I created a class called Truck, which inherits fr0m a class called Vehicle. View here.

Pull Up:

When working with classes and superclasses, Pull Up refactoring is very useful. It allows you to move class members and methods from a subclass up into the superclass.

Push Down:

Push Down is the opposite of Pull Up refactoring. It pushes a superclass member down into a subclass.

And that’s it for this time, note that those are only half of the capabilities of NetBeans refactoring. I am going to go through the other half in a following post soon. If you have any question or comment, do not hesitate to contact me.

Features

External Sources
A solution is not limited to sources included in your projects, but also contains sources that were used to build your libraries. Some companies publish parts of their sources using the Source Server feature of debug information files (PDB).

Structured Patterns
ReSharper 5 can address this demand. You can set up your own code patterns, search for them, replace them, include them in code analysis, and even use quick-fixes to replace! Building patterns and enforcing good practices has never been this easy. Corporate and team policies, your own frameworks, favorite open source libraries and tools

Project Refactorings and Dependencies View

Call Tracking
Find usages

Value Tracking
Value Tracking gives you important information about data flow in your program.

Technologies and Languages

Visual Studio 2010

C# 4 and VB10
New language versions nowadays appear at a great speed, and ReSharper team works hard to support them right when you need them. ReSharper 5 provides beta support for C# 4 and VB10, as Visual Studio 2010 does itself. Variance, dynamic types, named arguments and optional parameters, embedded COM assemblies — all of these features are supported in the new ReSharper.

ASP.NET MVC
ASP.NET MVC deserved our special attention: special syntax highlighting, inspections, navigation to and from action or controller, and even actions to create new types and methods from usage in pages.

Inspections

Solution-Wide Warnings and Suggestions

Upgrade-to-LINQ Actions
With C# 3.0 and LINQ, developers are able to write data-intensive code more easily by directly describing their intent to the compiler. However, years of imperative programming left us with tons of foreach-style code waiting to be upgraded. ReSharper 5 detects parts of your code that can be rewritten using the new LINQ syntax and offers to perform the conversion automatically

Use IEnumerable Where Possible
With the power of LINQ, IEnumerable is more than enough to pass a collection of values. So why restrict yourself with an API requiring you to pass old-school arrays, Lists and ArrayLists? ReSharper will scan your code base to detect methods that can safely return and accept IEnumerable instead of a more specific type.

Other improvements

Native NUnit Support

XML Formatting

JetBrains .NET Tools Blog » Blog Archive » ReSharper 5.0 Overview.

Developer Express and Microsoft are proud to announce a new version of CodeRush licensed exclusively for C# developers working in Visual Studio. The new product is called CodeRush Xpress, and it includes a fresh selection of hand-picked features taken from CodeRush and Refactor! Pro.

Download now

Here’s a sampling of what you get:

Find any File or Symbol…

Go to any file or symbol in the solution efficiently.

Type in a few letters of the name to filter…

Or hold down the SHIFT key to filter only on uppercase letters…

Uppercase characters can appear anywhere. Any uppercase characters not specified in the filter are highlighted in blue…

The uppercase letters need not be sequential. Notice how “RD” in the screen shot below matches both “ResolveDelegate.cs” and “ResolveCallbackDelegate.cs”.

Tab to Next Reference

This is a really cool navigation feature that takes you to the next (and previous) reference just by pressing the TAB key (or SHIFT+TAB to go backwards) when the caret is inside an identifier, member, or a type. For example, in the following code, the caret was inside the last Person type reference (in the “newPerson()” instantiation call) when the TAB key was pressed, causing the Person reference at the top of the file to become highlighted.

Expand/Shrink Selection

This feature allows you to increase a selection by logical blocks, or decrease an expanded selection by the same logical blocks. This feature is perfect when refactoring, since many refactorings work on a contiguous selection of code (e.g., extract method, introduce local, etc.).

TDD-Style Intelligent Declaration Based on Usage

Place the caret on any undeclared element in your code and press the Refactor/Code key (CTRL+`) to see a list of intelligent suggestions for the type of the new variable. For example, in the screen shot below two appropriate types are suggested, even though Console.WriteLine has many overloads that accept a wide variety of types.

You can even turn a function call or property access into a variable declaration.

This makes writing code with Visual Studio’s Intellisense really fast. Just use Intellisense to produce the property reference or function call, and then press the Refactor/Code key to declare a new local variable of the appropriate type. Here’s an example with a function call—notice the caret can be just about anywhere on the function call, even at the end of the line.

You can even declare a local from a simple instantiation, like this:

And it’s worth noting you can declare all kinds of elements based on usage, not just locals. Anything you need types, members, fields—the full list of elements that can be declared appears below.

Professional Grade Refactorings

CodeRush Xpress includes many powerful refactorings to help improve the quality of your code. For example, consider the following:

private static void ShowInt(int n)
    {
Console.WriteLine(n);
    }
private static void ShowEntries(List<int> entries)
    {
      entries.ForEach((Action<int>)ShowInt);
    }

With the caret on the ShowInt method reference, you can press the Refactor! key…

and then select Inline Delegate. This will produce the following code:

private static void ShowEntries(List<int> entries)
    {
      entries.ForEach(delegate(int n)
                      {
Console.WriteLine(n);
                      });
    }

Notice the caret is on the delegate keyword. You can immediately press the Refactor! key again…

Note that we can go in two directions now. We can either convert the anonymous method to a named method (in essence reversing the Inline Delegate refactoring we just performed), or we can take it a step further and compress the anonymous method into a lambda expression. Choosing Compress to Lambda Expression, we get the following:

private static void ShowEntries(List<int> entries)
    {
      entries.ForEach(n => Console.WriteLine(n));
    }

CodeRush Xpress is loaded with powerful refactorings taken from Refactor! Pro. One of our favorites, Extract Method to Type, allows you to extract a method from one type into another, updating both the calling code and the extracted method appropriately. For an example, consider the following code:

class Person
  {
public string Name { get; set; }
public  class="hiddenSpellError" pre="public ">bool IsAnOrphan { get; set; }
public Person Mother { get; set; }
public Person Father { get; set; }
  }
// ...
class BabyMaker
  {
public Person MakeOne(Person mother, Person father, string name)
    {
Person newBaby = new Person();
      newBaby.Name = name;
      newBaby.Mother = mother;
      newBaby.Father = father;
      newBaby.IsAnOrphan = newBaby.Mother == null && newBaby.Father == null;
return newBaby;
    }
  }

Notice that the code in the MakeOne method contains a local variable that’s an instance of type Person, and that code sets the IsAnOrphan property. There is some logic in this method that pertains to Person, but it feels like it’s in the wrong class!

We already have the class Person in our solution, so it makes sense to move some of this code to the proper class. With CoderRush Xpress installed, all we need to do is select the code we want to move….

Press the Refactor key…

And choose “Extract Method to Person“. CodeRush Xpress analyzes the selection and determines there’s at least one local variable of a type you have declared elsewhere in the solution. Now let’s apply this refactoring…

Press the UP and/or DOWN ARROW keys to select a location for this new method, and press ENTER to commit. Give the method a meaningful name…

Cool. Now we have the logic (that should have been inside Person to start with) right where it belongs. Notice how the new SetParents instance method works on the instance itself (compare that code with the original code that operated on the newBaby local). The code is easier to read and cleaner in both locations.

Notice also that tiny dark blue triangle, in the code above. That’s a stack-based marker, and CodeRush Xpress drops markers automatically whenever you apply a refactoring or TDD-style declaration that takes you away from the original location. You can jump back at any time to the top marker on the stack by pressing ESCAPE.

There are many more refactorings and cool features in CodeRush Xpress. This is just a preview. Here’s the full list of what you get:

Editor Features

• Duplicate Line
• Highlight Usages
• Clipboard Features
  • Smart Cut/Copy
  • Paste Replace
• Enhanced Selection Abilities
  • Extend/reduce selection
  • Camel-case selection

Navigation Features

• Camel-case Navigation
• Tab to Next Reference
• Go to File
• Go to Symbol (QuickNav)

TDD – Declaration from Usage

• Types
  • Declare Class
  • Declare Delegate
  • Declare Enum
  • Declare Enum Element
  • Declare Interface
  • Declare Struct
• Members
  • Declare Constructor
  • Declare Event Handler
  • Declare Getter
  • Declare Method
  • Declare Property
  • Declare Property (auto-implemented)
  • Declare Property (with backing field)
  • Declare Setter
• Variables
  • Declare Field
  • Declare Local
  • Declare Local (implicit)

Refactorings

• Add/Remove Block Delimiters
• Combine Conditionals (merge nested “If” statements)
• Compress to Lambda Expression
• Compress to Ternary Expression
• Convert to Auto-implemented Property
• Convert to Initializer (use object/collection initialize when possible)
• Create Backing Store (converts Auto-implemented Property to standard Property with get and set)
• Decompose Initializer
• Decompose Parameter
• Expand Lambda Expression
• Expand Ternary Expression
• Extract Method to Type
• Flatten Conditional
• Introduce Local (introduce variable)
• Inline Delegate
• Inline Temp (inline variable)
• Make Explicit
• Make Implicit
• Move Type to File
• Name Anonymous Method
• Name Anonymous Type
• Reverse Conditional (invert “if”)
• Split Conditional (split complex “If” statements)
• Use StringBuilder
• Use String.Format

CodeRush Xpress for C#

Design, test (developer), implement, code-review and refactor an application.
Therefore, design, test, implement, code-review and refactor set of features of an iteration.
And therefore design, test, implement, code-review and refactor a feature.
And therefore design, test,implement, code-review and refactor a module.
And therefore design, test, implement, code-review and refactor a class.
And therefore design, test, implement, code-review and refactor a method.
Do it properly and not just because your idol programmer do it so.

An iteration that is
       properly designed,
       properly tested,
       properly implemented,
       properly code-reviewed, and
       properly refactored
will
       open the door of the next iteration.
The time spent by the team is never a waste.
The target users will find value on the application.
The stakeholders will be satisfied therefore happy.

Now, what would you do?
Stay the same?
If you are doing these already, then that is absolutely great!
But if not, then do the opposite and enjoy the difference!

Andrew Woodward recently posted a comparison of his test-driven Prime Factors solution to one written by Uncle Bob. In the comments, someone suggested that Andrew use an iterator instead so I thought I’d give it a try.

First, let’s repost the original code:

private const int SMALLEST_PRIME = 2;

public List<int> Generate(int i)
{
    List<int> primes = new List<int>();
    int divider = SMALLEST_PRIME;
    while (HasPrimes(i))
    {
        while (IsDivisable(i, divider))
        {
            i = AddPrimeToProductsAndReduce(i, primes, divider);
        }
        divider++;
    }
    return primes;
}

private bool IsDivisable(int i, int divider)
{
    return i%divider == 0;
}

private bool HasPrimes(int i)
{
    return i >= SMALLEST_PRIME;
}

private int AddPrimeToProductsAndReduce(int i, List<int> primes, int prime)
{
    primes.Add(prime);
    i /= prime;
    return i;
}

By switching our method to return IEnumerable<int>, we can replace the primes list with an iterator. We will also remove the AddPrimeToProducts functionality from that helper method since we don’t have the list any more:

public IEnumerable<int> Generate(int i)
{
    int divider = SMALLEST_PRIME;
    while (HasPrimes(i))
    {
        while (IsDivisable(i, divider))
        {
            yield return divider;
            i = Reduce(i, divider);
        }
        divider++;
    }
}

private int Reduce(int i, int prime)
{
    return i / prime;
}

I think this is a good change for three reasons:

1. There’s nothing about the problem that requires a List<int> be returned, we just want a sequence of the factors.
2. AddPrimeToProductsAndReduce suggested that it had a side effect, but exactly what wasn’t immediately obvious.
3. It’s much easier to see what values are being included in the result.

That said, I think we can clean this up even more with a second iterator. Specifically, I think we should break out the logic for our candidate factors:

private IEnumerable<int> Divisors
{
    get
    {
        int x = SMALLEST_PRIME;
        while (true)
            yield return x++;
    }
}

Which allows us to separate the logic for generating a divider from the code that consumes it:

public IEnumerable<int> Generate(int toFactor)
{
    foreach (var divider in Divisors)
    {
        if (!HasPrimes(toFactor))
            break;

        while (IsDivisable(toFactor, divider))
        {
            yield return divider;
            toFactor = Reduce(toFactor, divider);
        }
    }
}

We should also eliminate the negation by flipping HasPrimes to become IsFactored:

public IEnumerable<int> Generate(int toFactor)
{
    foreach (var divider in Divisors)
    {
        if (IsFactored(toFactor))
            break;

        while (IsDivisable(toFactor, divider))
        {
            yield return divider;
            toFactor = Reduce(toFactor, divider);
        }
    }
}

private bool IsFactored(int i)
{
    return i <= 1;
}

This does introduce a (very) minor inefficiency in that the Divisors enumerator will MoveNext() one extra time before breaking out of the loop, which could be mitigated by checking IsFactored both before the foreach and after the while loop. Less readable, insignificantly more efficient…take your pick.

The other advantage to breaking out the logic to generate Divisors is that we can easily pick smarter candidates. One option is to skip even numbers greater than 2. An even better optimization takes advantage of the fact that all primes greater than 3 are of the form x±1 where x is a multiple of 6:

private IEnumerable<int> Divisors
{
    get
    {
        yield return 2;
        yield return 3;
        int i = 6;
        while (true)
        {
            yield return i - 1;
            yield return i + 1;
            i += 6;
        }
    }
}

Implementing this sort of logic in the original version would have been much more difficult, both in terms of correctness and readability.

Well now it’s just a matter of debugging my code. I suppose writing tests would be the ideal thing to do, but I think there is just a stupid typo in there somewhere that I’ll have to look for.

Ok. I had some ideas while I started working. It pretty much went like this:

1. Reading in the times is working but assumes they are always in full format (ie 00:00:00,000) and does not handle 00,000 situations.
2. the to_s method is terrible, I’ve only used sprintf once or twice in PHP so it’s no wonder I didn’t think of it right off. That cleaned it up quite a bit.

So after figuring out a way to read in the times and account for partial time entries, I did a bit of refactoring and testing and found out that it’s working now, horray!
I just thought of another, probably easier way this could have been accomplished. If I had taken the file times, converted them to milliseconds and then added/subtracted the converted input times then spit them back out as HH:MM:SS,mmm it might have been less verbose code, but I think this was a good exercise to learn a bit about Ruby classes. And anyways, my code works and that’s all that counts, right?

http://charpcfn.pastebin.com/f594e4212

That’s my submitted code!

Can’t wait for the next challenge :]

edit: If I find myself with some extra time I will probably go back and write some unit tests and maybe try making it a Gem as practice since there is still a while before the next challenge starts.

Flex Builder 3, an eclipse~ IDE for flex and actionscript based project development lacks few primary code indentation and refactoring functionalities by itself.

Searching for some other technical requirement drove me to Flex Formatter, a third party project on source! Cheers, its BSD license!

This tool is really small but very essential and useful plugin

Flex Formatter tools

Many times it happens that code is written in hurry to achieve some short term goal. Either some efforts need to invest to refactor and indent the code, or else go for Flex Formatter.

Built in capability to generate ASDoc is also impressive! However, I suppose, all these features, of flex formatter have been covered with Flash Builder 4.

First, HamQuest is now in an assembla space:

http://www.assembla.com/spaces/hamquest

Second, there has been a lot of refactoring in the HamQuest code base.

I’m finally tackling the “get the creatures into xml” task, and it is proving to be very challenging, and the reason it is challenging is because of the corner I painted myself into with how the creature that represents the player is represented in code.

Slowly but surely I’m starting to unravel the issue, but not without pain, and I’m surprised the thing still actually works after what I just did.

A creature on a map is represented in code by a Creature object.

A Creature object holds the state of the creature (mostly the wounded state), and an index into a creature table.

The creature table consists of two types of object: CreatureDescriptor and a PlayerDescriptor, which derives from CreatureDescriptor.

A CreatureDescriptor is just that: a description of the general type of creature.

A PlayerDescriptor is more than that: it also contains the current state of the player.

The intent was noble: make players and creatures use the same rules for the most part, and only differ when they actually differ in behavior.

In a CreatureDescriptor, the attack value is static. A goblin always has an attack value of 2 no matter what, and nothing will change it ever.

In the PlayerDescriptor, the attack value depends on the weapon equipped by the player.

Now that I’m moving both types of descriptor into the “property bag” model that I put the Items into, I’m using a generic function to grab out the values, but the property bag knows nothing of the values it holds… it just holds them.

So, I “cleverly” wrapped a value into a new “StatisticHolder” class, so that the same looking call can get both the CreatureDescriptor attack value in its own static way, and will get the dynamic value from PlayerDescriptor.

So now CreatureDescriptor is completely empty, and ready for moving to XML, and PlayerDescriptor is not.

Of course, I’m not entirely sure that there is a need to put the player descriptor into xml as a whole.  It may be good enough to put some sort of “base statistics” for the player, and have the player descriptor copy from them, and simply add the PlayerDescriptor to the end of the Creature List, but load the others from xml as originally planned.

In any case, one step closer to the goal, along with the change of almost all enums into static classes with const strings, which may seem crazy and untypesafe (and it is!) but with the mind I have for extensibility of the project, it’ll make sense in the end.

In any case, you can check out the code at assembla, if you want.  Try not to point and laugh.

Coming back to code that is “aged” to any extent (HamQuest is about a year old as a code-base), it is easy to spot the flaws and quick decisions that painted the code into a corner.

Normally I think “This code sucks! I totally need to re-write it!”

But then I asked myself a very simple question: “You have written games a hundred times. You have rewritten those games another hundred.  Since when has that ever actually helped you finish any of them?”

So I’ve been slowly going over the code.  In many way, software development is more like making bread.  We add stuff, we remove stuff, we mix stuff around.

What started out as a single executable has turned into an executable and two dlls.  Originally I had just split out a single dll for the game itself, but once I had done that, I could see that there were a number of classes that were generic (something of a pun as most of the classes are generics) enough that they didn’t have anything to do with the game specifically.  There is now a dll called PDGBoardGames, which includes things like a Board class and a Maze class, both of which generic enough that they can be reused whenever I need a board or maze provided I remain in .Net land.

As I keep pulling stuff out of code and into XML files, more and more of the existing classes become unnecessary.  Item management has had the most work done, and there is not a single mention within the ItemTable class about any specific item.  Everything is either in the XML file, or derivable from the data in the xml file.

So, my usual thoughts about a codebase like HamQuest is “If I had done it right in the first place, it wouldn’t be like this.”  But I don’t think that way this time.  As far as codebases go, HamQuest isn’t all that bad or convoluted, which I attribute to my having worked on code for a long time, so a number of good habits have formed along the way.

However, I have spent the last few weeks working over the code and making it do exactly the same thing it did before, just a little more flexibly.  Thankfully, I haven’t had any performance hits.

Two of the most typical consultant’s job are trying to save a failing project or implement new features and fix bugs within a project which code is not as clear or as good as one wishes.

Uncle Bob mentions that if all checked in code is a little better than the code which was checked out, the average code quality will be higher than before. If we keep proceeding this way, the project’s overall quality will be much better after a couple weeks.

Those projects which does not contain such good quality code are the ones were we can learn a lot about baby-steps changes and code-improvement: you can improve anything and everything.

The same thing would apply with tests. If whenever we make a change to some piece of non-tested code, one writes its respective code, really soon we will have a better designed and testable software.

Paul Hammant once told me he used to love to face those projects and implement new features/refactor the project without breaking it, while introducing test cases – usually those projects do not contain any automated tests.

It takes a lot of guts to face those changes. Imagine a project which contains  no automated tests at all and you wish to change a functionality. If 100% code coverage is not enough, imagine 0%…

The first step would be to create an automated test which works for the functionality you are willing to change (the way it works right now). Your job is to get the test passing and it should probably take some time only to get it written, because the code was not designed for tests.

Let’s see an example of code written while not thinking about tests. The first class shows a thread local based code which allows one to access a 3rd-party system, i.e. a web service:


public class Connections {
private static final ThreadLocal<Resource> resource = new ThreadLocal<Resource>();
static { // ... startup code }
public static Resource getResource() {
return resource;
}
}


And now we show a common web service access using the above mentioned class:


public class Orders {
public static List<Order> active() {
List<Order> orders = Connections. getResource().list();
for(Iterator<Order> it = orders.iterator(); it.hasNext();) {
Order order = it.next();
if(order.wasCancelled()) it.remove();
}
return orders;
}
public static void add(Order order) {
return Connections. getResource().post(order);
}
}


Note that this code works just fine. A software could be running it for a while until someone asks to change the list criteria for all clients.

Lets suppose that the logic has changed, requiring that one should only be allowed to see the orders which were not cancelled and not yet delivered at the same time. You could simply implement the change in that Orders.all method or start implementing tests right away.

The process of creating an automated test for Order.all shows one of the typical problems while trying to create tests in projects which were not design for them: tight coupling between classes.

This tight coupling usually appears in two forms: instantiating specific types (i.e. new XXXX) or statically accessing members of another type. In both situations, a test case implies also accessing the other type.

The problem is, how to create a unit test case, without changing its code? Well, one could write some code which would actually access the 3rd party system, but that’s not our aim with this test. We just want to assure that the for (and including if) was written correctly.

This case can be refactored with the use of dependency injection but we need to be careful, our changes could break the functionality.

Although Orders and Connections are tightly coupled, we can introduce a new parameter within the Orders class. Let’s


public class Orders {
private final Resource resource;
public Orders(Resource resource) { this.resource = resource; }
public static List<Order> active() {
List<Order> orders = resource.list();
for(Iterator<Order> it = orders.iterator(); it.hasNext();) {
Order order = it.next();
if(order.wasCancelled()) it.remove();
}
return orders;
}
public static void add(Order order) {
return Connections. getResource().post(order);
}
}


Notice that I did not make any changes to the add method, because I am still not going to write any test case related to it.

In order to introduce the new parameter within the Orders() constructor, its a good idea to use an ide feature and make everyone who is calling its constructor to start invoking “new Orders(Connections.getResource())”…

This way, no functionality was changed at all, the project is compiling and working as before and we are ready to create our test case, which shall pass a mocked Resource to the constructor and allows us to run this unit test.

As soon as the test is passing, one is ready to make changes to the business logic contained within the list method itself.

This is one of the possible ways of dealing with legacy non-tested code in order to incrementaly built a well-enough-covered codebase.

In my last post I showed how to get the GUI aspect of a New Wizard for the creation of a new project type up and running rather quickly. In my never ending attempt to be a good developer citizen it is now time to stop and refactor.

You might think we haven’t actually written enough code to refactor (we have 3 Java files in total). That would be true except for the three strings in our wizard code. I could wait until there is more to do, but why not refactor now when it will begin to develop muscle memory for that particular task?

First change:

    _pageOne = new WizardNewProjectCreationPage("Custom Plug-in Project Wizard");

to:

    _pageOne = new WizardNewProjectCreationPage(PAGE_NAME);

and put the string at the top of the class:

    private static final String PAGE_NAME = "Custom Plug-in Project Wizard"; //$NON-NLS-1$

Next change:

    public CustomProjectNewWizard() {
        setWindowTitle("New Custom Plug-in Project");
    }

to:

    public CustomProjectNewWizard() {
        setWindowTitle(WIZARD_NAME);
    }

and put the new constant at the top of the class:

    private static final String WIZARD_NAME = "New Custom Plug-in Project"; //$NON-NLS-1$

The other two strings should be replaced by using the Eclipse Externalize Strings mechanism. With the CustomProjectNewWizard.java open in the editor select Source –> Externalize Strings (or move the cursor to one of the strings and press Ctrl+1).

When the Externalize Strings dialog opens check the box for Use Eclipse’s String Externalization Mechanism. If you like the key value then leave them alone, but I prefer to have a variable name that conveys some level of information so I changed the keys to match the strings; so the CustomProjectNewWizard_0 becomes CustomProjectNewWizard_Custom_Plugin_Project and CustomProjectNewWizard_1 becomes CustomProjectNewWizard_Create_something_custom.

In addition, click Configure which is next to the Accessor Class dropdown field. Change the Class Name from Messages to NewWizardMessages. Click OK to finalize your decision.

Press Next in the Externalize Strings dialog to take a look at what the change will look like. What you should see are the strings replaced with a reference to a new class that just got generated.

    _pageOne.setTitle(NewWizardMessages.CustomProjectNewWizard_Custom_Plugin_Project);
    _pageOne.setDescription(NewWizardMessages.CustomProjectNewWizard_Create_something_custom);

Look in the Package Explorer for the new class. It should be in the same package as the Wizard code. The magic? At runtime Eclipse reads the property file named messages.properties and fills in the static fields with the values in the file. You can add to the file through the Externalize Strings dialog as you add more strings that need to be externalized.

That is the extent of the refactoring based on what has been done so far.

Refactoring can sometimes seem trivial, but it will pay many dividends later when a string needs to be changed, or internationalized, and the only thing that needs to be done is to create a new properties file.

It’s been a long time since I last updated this site.  I’ve been wanting to for so long but have just been too busy (or lazy) to do anything.  Anyway since there is so much stuff in my head i’m thinking to just blurt it all out, things that I’ve learned, things I want to change, etc.

Lets start with the title.

Rather than “rumz’s tech notes” i think i want to just maintain this one blog, soooo…. the title must be appropriate. I dont want to just post about tech stuff, so how about “rumz / learn / notes”  ayan!  now i can post about me, learning stuff (not just tech stuff), and any sort of stuffage i want. there are categories and tags anyway so searching should be a cinch…   hmmm lets digress some more…

Marriage!

Ever since I got married I thought that I was learning less… but the opposite was true!  I’ve learned so much (loving it!)  from Jay than i would have learned had i still opted to be single.  Well, the big thing i really learned also is you gotta manage your time!  With work and jay and my personal hobbies all in the way, plus quiet time, i really have to set time aside for everything (not to mention how to manage emotional and lack-of-money stress–  lol another side effect of marriage).  More on that later.

Things I’ve learned and am still learning (and need to learn)!

As usual I am reading lots of books (but not as many as before) and all these things are great but wouldnt it be greater if other people learned from them?  as of a few days/weeks ago I am starting out learning python.  google uses it, so i think i should be learning it.  linux learning has diminished but i want to remedy that.  i need to start learning accounting so i can get my finances in order.  food and diet are extremely important now that im getting much less exercise than before.   managing people is another essential skill that needs putting on the table since i work with a large team.  photography is an awesome way of expressing oneself and i really like this new hobby.

Beliefs and Spiritual Stuff

Its about time i started posting more about what is really important.  This might look to be a really drastic change in terms of what stuff i used to write about, but its a paradigm shift that is long needed.   i totally believe that our actions now have an impact on us and ourselves, and ultimately, the afterlife.   maybe if i quote the bible on this one i would make more sense

“What good is it for a man to gain the whole world, yet forfeit his soul?”

Refactoring

Rewriting something so that it is written differently, but ultimately “means” the same thing. E.g. in Math, you can refactor x + xy to x( 1 + y ). These two statements (x+xy) and (x(1+y)) mean exactly the same thing mathematically, but they’re just written differently. e.g. 2 in programming, refactor is used more loosely. You can refactor a bunch of code which means you rewrite the code to do the same intended thing, but in a better way (more efficiently, or with more adherence to OOP principles, or rewrite it to remove bugs).

A while back I put together a quick and dirty implementation of a FindControl extension method:

public static T FindControl<T>(this Control root, string id) where T : Control
{
    Control c = root;
    Queue<Control> q = new Queue<Control>();

    if (c == null || c.ID == id)
        return c as T;
    do
    {
        foreach (Control child in c.Controls)
        {
            if (child.ID == id)
                return child as T;
            if (child.HasControls())
                q.Enqueue(child);
        }
        c = q.Dequeue();
    } while (c != null);
    return null;
}

It got the job done (if the control exists!), but I think we can do better.

Refactoring with Iterators

My first concern is that the method is doing too much. Rather than searching for the provided ID, the majority of the code is devoted to navigating the control’s descendents. Let’s factor out that logic into its own method:

public static IEnumerable<Control> GetDescendantControls(this Control root)
{
    var q = new Queue<Control>();

    var current = root;
    while (true)
    {
        if (current != null && current.HasControls())
            foreach (Control child in current.Controls)
                q.Enqueue(child);

        if (q.Count == 0)
            yield break;

        current = q.Dequeue();
        yield return current;
    }
}

The new method is almost as long as the old one, but now satisfies the Single Responsibility Principle. I also added a check to prevent calling Dequeue() on an empty queue. For those that have studied algorithms, note that this is a breadth-first tree traversal.

Now we can update FindControl:

public static T FindControl<T>(this Control root, string id) where T : Control
{
    Control c = root;

    if (c == null || c.ID == id)
        return c as T;

    foreach (Control child in c.GetDescendantControls())
    {
        if (child.ID == id)
            return child as T;
    }
    return null;
}

With the control tree traversal logic extracted, this updated version is already starting to smell better. But we’re not done yet.

DRY? Don’t Repeat Someone Else, Either

My second concern is how we’re checking for the ID in question. It’s not that the equality operator is a bad choice, as it will work in many scenarios, but rather that it’s not consistent with the existing FindControl method. In particular, the existing FindControl understands naming containers (IDs that contain ‘$’ or ‘:’). Rather than implement our own comparison logic, we should just leverage the framework’s existing implementation:

public static T FindControl<T>(this Control root, string id) where T : Control
{
    if (id == null)
        throw new ArgumentNullException("id");

    if (root == null)
        return null;

    Control c = root.FindControl(id);
    if (c != null)
        return c as T;

    foreach (Control child in c.GetDescendantControls())
    {
        c = child.FindControl(id);
        if (c != null)
            return child as T;
    }
    return null;
}

Fun fact: FindControl will throw a NullReferenceException if id is null.

Refactoring with LINQ

So we have extracted the descendant logic and leaned on the framework for finding the controls, but I’m still not quite satisfied. The method just feels too…procedural. Let’s break down what we’re really trying to do:

1. Look at the current control and all its descendants.
2. Use FindControl on each with the specified ID.
3. When we find the control, return it as type T.

As the subheading might suggest, we can express these steps quite nicely with LINQ:

1. var controls = root.AsSingleton().Concat(root.GetDescendantControls());

2. var foundControls = from c in controls
                       let found = c.FindControl(id)
                       where found != null
                       select found;

3. return foundControls.FirstOrDefault() as T;

Behind the scenes, this is how I might have thought through this code:

1. We use AsSingleton() (my new preferred name, to align with F#’s Seq.singleton, for AsEnumerable(), which I introduced here) and Concat() to prepend root to the list of its descendants, returned as a lazy enumeration.
2. We use a query over those controls to retrieve matches from FindControl(), again returned as a lazy enumeration.
3. We grab the first control found, or null if none match, and return it as T.

Because all our enumerations are lazy, we put off traversal of the entire control tree until we know we need to. In fact, if our ID is found in the root control, GetDescendantControls() won’t even be called! Through just a bit of refactoring, we have both an efficient and readable solution.

For completeness, here’s the final version with a more descriptive name to contrast with the existing FindControl():

public static T FindDescendantControl<T>(this Control root, string id) where T : Control
{
    if (id == null)
        throw new ArgumentNullException("id");

    if (root == null)
        return null;

    var controls = root.AsSingleton().Concat(root.GetDescendantControls());

    var foundControls = from c in controls
                        let found = c.FindControl(id)
                        where found != null
                        select found;

    return foundControls.FirstOrDefault() as T;
}

I have added these methods, along with AsSingleton() and a host of others, to the SharePoint Extensions Lib project. Check it out!

I just did not feel like writing for my little blog this week, as my thoughts are focused both on my company, Geiger (www.geiger.com promo) and the interesting and fun components of the Promotional Products industry that I am gleaming from the great people here.  So, external inputs had little input into my world this week.

To put it into a visual, think of a room filled with flip charts of drawings, text, snapshot pictures of people, applications, hardware, department and division names, roles and processes.  That is what my head is filled with and yes, several pages of flip charts, because big thoughts must be on big paper.

So, what do I write this week that would provide something worthwhile and also have my perspective – rule #1 of a good blog.  Well, without getting into too much trouble, it is that these first 45 days at a new company provide you a unique vision of people, processes and relationships between those two things.  Why could we not capture this vision more than once, when we start with a new organization?  There is a way I am learning, it is called un-learning and re-learning.

The book by Stephen M. Covey (son of Stephen R. Covey) called The Speed of Trust discusses the importance of un-learning.  The first time you learn something, like I am doing now, you are exposed with very little bias to limit your learning.  However, once you learn enough to get started (regardless of what it is), the rest of the training is slanted based on your initial biases which are difficult to avoid due to the manner in which our brain captures and interprets information.

Another book Pragmatic Thinking & Learning by Andy Hunt discusses in detail using the Dreyfus model how the brain learns.  Mr. Hunt offers a way to train your mind; he calls it refactoring your wetware, to recreate these first 45 days of unique vision.  I will let the few readers of this blog to explore those writers and their works for their own impressions.

But let me impress upon you this perspective of un-learning and re-learning on an annual basis.  For us in the technology realm, it is critical for us to un-learn and re-learn so that we can provide the proper judgments of emerging technologies and their impact on our businesses.  I know I have in the past become enamored with the technologies that took the team of people I worked with, months, if not years to design and implement.  When new technologies emerged that could replace it, the review process compared the old technology versus the new technology instead of comparing what the business people and processes do versus what the new technology does.

Comparing it anew as if the old technology did not exist was not part of the process.  But, it should have been.  Because we continuous change the people and the processes adapting (evolving) the old technology to these change whole new ways of doing things are often not part of the process.  Old technology evolves, it does not revolutionize as a new technology could possibly do.

The example of companies changing their marketing firms every 8 to 10 years comes to mind.  Often the issue is not that the old marketing firm is performing poorly, just the customer company knows that a new perspective could bring better marketing results.  The customer company un-learns by hiring a new firm so they can re-learn.

So a business can hire a new firm every few years to un-learn and re-learn, which results in us getting the benefits from this process spread out over far to many years and also ending close relationships that have served us well.  Or, develop the process of internal un-learning and re-learning, along with a utilizing a new firm strategically to perform certain functions tactically that create a new perspectives and thus new options.

I strongly recommend The Speed of Trust (The One Thing That Changes Everything) and Pragmatic Thinking & Learning (Refactor Your Wetware) to help you understand more in depth these processes.  For me, I am re-learning those parts of technology that I have experienced before by asking those around me to teach me anew, from their perspective.

As developers, after working on the same project for a while, we start to remember sections of our code base which aren’t quite ‘up-to-par’ with either team or industry standards. We begin dreading working in those areas of the project and sometimes even avoid stories or tasks involving these problem areas. Our first instincts should be to refactor the area or clean it up in some way so that these smells do not haunt the next person who must work in that area of the system. Unfortunately, it is not always as simple as just fixing the issue immediately and soon a small task can become bloated when we head down those rabbit-holes of maintenance.

Our initial solution to this problem was to simply document these code smells on a white board beside our scrum board under a section called ‘Code Smells’. Each smell was represented by a card which could then be prioritized based on the impact it was causing. This was great because all of these problems in the back of everyone’s mind were now right there in our faces and even the business could see them. It was now more apparent what might cause you issues when you worked on a given story. These code smells were still addressed as part of stories if it made sense to fix them immediately but we could also do some work or investigation on the smells during short periods of spare time, often before lunch or at the end of the day.

This method did work for quite some time; however it was soon apparent that it was not just bad code which was slowing us down. Other issues arose such as deployment complexity, test runtimes, etc. which did not seem appropriate to classify as code smells even though they were undoubtedly hurting our team’s velocity. We came up with the idea of renaming our Code Smells section to ‘Speed Bumps’. This new name gave us a place to track anything and everything which was slowing us down. They are still addressed in the same fashion, either as part of a story or during spare time. The benefit of the rename simply gave the team more certainty when adding issues to the list since if there was something limiting their productivity; they were encouraged to either deal with it immediately or add it to the list. This makes any technical debt in the project more manageable because everyone becomes aware of them and they can be prioritized once recognized.

I am curious if any other development teams out there utilize a similar or even completely different strategy for addressing technical debt. What works for you?

By: Jesse Webb

In the past, I inherited a web project where all coding logic was in the web page classes.  This made writing unit tests very difficult.  I converted these pages to use MVP, or Model View Presenter design pattern.  MVP allows you to test the Presenter and business logic without having to test the View.  A technique I developed was to move methods from one class to another using Resharper.  I believed that this was a refactoring that Resharper should offer in the future.  To achieve this, I used Resharper to do the following.

1) convert a method in the view class to a static method, Resharper will add a parameter for the View object.

2) move the method to the Presenter class, Resharper will redirect all references.

3) if I did not already have the Presenter as one of the parameters, I add one in.

4) convert the method back to a non-static method in the Presenter class, Resharper would ask which parameter should be converted to “this”, I select the Presenter object.

I then further extracted repository, model, security, and other types of code out of the Presenter using the same technique.  Once I had the code in MVP pattern, I mocked the View and tested the Presenter independently.

Today, I attempted to change a java package name. I did a right click at the package name and there’s no “Rename.”

What I did is creating a new package, say package.my.new. Then I go to package.my, right click > refactor> move and select package.my.new.

I then edited web.xml file, do a search replace from package.my to package.my.new and it works.

However, later I found that there’s a function “rename” under refactor. but I have not tried it. I will check it out next time.

Like any good non-blogger weblogger, I have been inactive on espressomind. While you haven’t seen any updates here, I have been reflecting on how I’d like to use espressomind.com.

The lab notebook idea doesn’t work for me. I can reflect further on why it doesn’t work in a future post, but it essentially comes down to this: I have an unstructured lab notebook, and finding structure on wordpress was not productive. With that said, look for the new espressomind soon.

PS – I came across three blogging I’s this morning. It’s a good discussion.

… and consider one or more test, just in case.

Currently I’m working in a project where , as usual, changes in requirements are very common, and that’s ok, we live in a world of agile projects were things like these are welcome. That is why we have a group of techniques to accomplish these changes (refactoring, version control, powerful IDEs, design patterns, etc.). The project was started by other development team some time ago, now a new team (I’m on it) is maintaining and changing it according to the new requirements.

When we have a new change to include in the system, basically we do things like:

• Limit the change with the business owners to understand why it is needed and what we must do.
• With the team, we design an initial model that include all the changes to support the new functionality.
• Measure the impact that these changes will have in the previous code.
• Here comes the funny part, refactor all the code to make it work with the new structure.
• Test the functionality to verify it works as before plus the new changes.

When the structure of the code makes difficult to find exactly how far the impact of a change will propagate (my case and of course we are trying to correct that), it is necessary to write, think or define some way to provide an infrastructure to test the system in order to make it work correctly and with that keep your good image with the customers.

This is where the post goes, remark the importance of having a way to test the functionality of a system that has already been deployed. We have had a bad experience about this, we didn’t have a clear way to test all the code that used to work before we implement a new change, as a consequence of this when the system is redeployed the users of it will face some awful problems and, of course, they will not be happy and you, as a developer, will have to work under pressure and believe me that is not good for anyone because it easily will lead to alter other functionality in order to get the previous one to work as desired.

To sum up consider these points due to bad testing:

• Work under pressure
• Create more problems instead of solving them
• Make a user unhappy
• Forget about the nice work you were doing before the error came up
• Redeploy the system in order to correct the error
• As a consequence of all the above, your schedule will be late

and now consider these points of good testing:

• Work on what you want to do
• Make a user (and you) happier
• Have some free time to spend in making the system and the user experience better
• Enjoy a productive day
• Sleep nice and peacefully at home

So what is better to do, in order to have a nice work environment? Yeah you are right, develop a way to test after a big refactor has been done.

Yesterday Ronin 0.2.1, code-name “notashellscript”, was released. That’s right, we finally surpassed the awkward 0.1.x phase. Although, I completely forgot to write about Ronin 0.2.0, code-named “solid”, which is where most of the action occurred.

Ronin 0.2.0 saw the complete refactoring and specing of the Platform code, which manages Overlays and their Extensions. Besides the huge amount of bug-fixes, modularization and renaming, Overlays can now have their own top-level lib/ directories. Also, all of the lib/ directories contained within an Overlay and it’s Extensions are added to the $LOAD_PATH upon activation. This allows for easier requiring of code embedded within Overlays.

Ronin 0.2.0 also saw the addition of the ronin/environment file, which loads all of the convenience methods, configuration from ~/.ronin/config.rb and starts Ronin’s Database. The environment file makes it easier to load up all of Ronin (minus the Platform code) in an IRB session and get hacking.

Grey bearded hackers bemoan how every exploit, library and framework have their own special leet diagnostic printing format. Some prefer the defacto “[*] Message” while others go for the saucy “{+} Message”. Well grey beards you have one more reason to bemoan, UI::Diagnostics was added to Ronin 0.2.0. The UI::Diagnostics module adds the print_info, print_warning and print_error methods to a class. The output of these methods are controlled by the UI::Verbose module.

Ronin 0.2.1, code-name “notashellscript”, had a couple but still important changes. Ronin 0.2.1 has dropped REXML in favour of Nokogiri for XML support. Nokogiri brings faster XML/HTML parsing and building to Ronin, providing it’s own set of bindings to libxml2.

UI::CommandLine was rewritten in Ronin 0.2.1. Now sub-commands are accessible by both the ronin sub-command --options style and git style sub-commands, such as ronin-command --options. The git style sub-commands provide a more direct way of calling sub-commands.

Many of Ronin’s other libraries received convenience sub-commands which simply start the Ronin console with the specific library pre-loaded. Ever wanted to jump right into Ronin Dorks or Ronin Scanners, now you totally can:

$ ronin-scanners
>> Scanners::Nmap.scan(:targets => '10.1.1.*', :syn_scan => true)
...

Finally, I’ve started to practice what I preach by setting up my own Ronin Overlay to experiment with. Of course, the Overlay is hosted on github.com, so feel free to clone and fork away. To install the Overlay under Ronin, use the following command:

$ ronin install git://github.com/postmodern/postmodern-ronin.git

So far, I’ve added an extension which parses the exploit lists on milw0rm.com. The milw0rm extensions is accessible within Ronin using the following code:

$ ronin
>> puts Ronin.milw0rm.remote.recent
...

Ironically, while testing the extension I noticed that milw0rm does not properly escape the titles of their exploits, resulting in unescaped < and > characters in their HTML.

Source: http://railstips.org/2008/12/30/move-it-to-the-model-and-use-tiny-methods

I’m updating an application that I first wrote two years ago and last updated one year ago. It has been amazing to see how much I have learned in the past two years. One of the requirements of the application is for the users to update their information each year. Just last year, I had code like this. Before you look at the code below, I want to warn you that it is not for the faint of heart. Never, ever do this.

<%- if current_user.roles.select { |r| r.title.include?('Pastor') }.size > 0 &&
    (current_user.email.blank? || current_user.address.blank? ||
     current_user.city.blank? || current_user.state.blank? ||
     current_user.zip.blank? || updated_at.year != Time.now.year) -%>
  <!-- show the update form -->
<%- else -%>
  <!-- show the list of forms to be completed -->
<%- end -%>

I would not lie to you. It was literally like that. A year later, I can barely tell what I was trying to do here. Imagine someone who didn’t know the application inside and out trying to work with code like that. Yikes! Here is my refactored version, that is far more descriptive.

<%- if current_user.needs_to_update_information? --%>
  <!-- show the update form -->
<%- else -%>
  <!-- show the list of forms to be completed -->
<%- end -%>

The benefit of this implementation is that any programmer can immediately tell what my intent is and that all the logic of determining whether or not the current user needs to update their information is moved to the model, where it belongs and can more easily be tested. So what are the steps that I took to get to that new method? First, I changed the if statement to the one above and then I moved all the logic into the user model like this.

class User
  def needs_to_update_information?
    roles.select { |r| r.title.include?('Pastor') }.size > 0 &&
      (email.blank? || address.blank? ||
         city.blank? || state.blank? || zip.blank? ||
         updated_at.year != Time.zone.now.year)
  end
end

This is only step 1. We are not done by any means. I can assure you that if you leave a method like this in your code, I will verbally attack you if I come across it. Let’s break this method down a bit, starting with the first conditional.

roles.select { |r| r.title.include?('Pastor') }.size > 0

This is horribly nondescript. What is my intent? Only pastors need to update their information and that is what this conditional checks. How about we add a pastor? method and use that in place. Also, I tweaked the condition to use Enumerable’s any? method (as suggested by David).

class User
  def needs_to_update_information?
    pastor? &&
      (email.blank? || address.blank? ||
         city.blank? || state.blank? || zip.blank? ||
         updated_at.year != Time.zone.now.year)
  end

  def pastor?
    roles.any? { |r| r.title.include?('Pastor') }
  end
end

That is much better, but why stop there? The next chunk of code that I see that we can pull out is the address stuff.

address.blank? || city.blank? || state.blank? || zip.blank?

The intent of these conditionals is to make sure that the user’s address is not blank, so I created an address_needs_updated? method.

class User
  def needs_to_update_information?
    pastor? &&
      (email.blank? || address_needs_updated? ||
         updated_at.year != Time.zone.now.year)
  end

  def pastor?
    roles.any? { |r| r.title.include?('Pastor') }
  end

  def address_needs_updated?
    address.blank? || city.blank? || state.blank? || zip.blank?
  end
end

Next up, I addressed updated_at.year != Time.zone.now.year. The intent of this conditional is to see if the user’s record has been updated in the current year. I pulled this out into an updated_this_year? method.

class User
  def needs_to_update_information?
    pastor? && (email.blank? || address_needs_updated? || !updated_this_year?)
  end

  def pastor?
    roles.any? { |r| r.title.include?('Pastor') }
  end

  def address_needs_updated?
    address.blank? || city.blank? || state.blank? || zip.blank?
  end

  def updated_this_year?
    updated_at.year == Time.zone.now.year
  end
end

That is probably about as far as I would go with this. So what are the benefits of all these changes?

The Benefits

• Moved business logic to the model where it is easier and more fun to test.
• More descriptive as to the intent of what is happening. Intent is really important. It is far more important for someone to understand why you are doing something than how you are doing something. There are many ways to do something, but there is only one intent.
• Smaller methods are easier to test than larger ones (and more fun). Testing large methods feels burdensome and often doesn’t provide enough coverage.
• Did I mention testing? It is easier and more fun to test models than views and small methods than large methods (yes, testing can be fun).

Getting back into this app, I learned that I have learned a lot in the past few years and I hope the error of my ways was beneficial for you too. I am in no way a refactoring expert and haven’t read the book on it, but if you are curious about refactoring, the techniques I used above appear to be Decompose Conditional and Extract Method.

“We are what we repeatedly do. Excellence, therefore, is not an act, but a habit.”
-Aristotle

Software Development, an Art or a Science? It’s something I’ve been thinking about lately, particularly as it strikes me that at times, there are so many similarities with Art. I’m ignoring the vaguely pretentious concept of software as a “creative space”, and instead focused on the developers actually being “finished”. Like Artists, knowing when a piece of code has been re-factored sufficiently and should be “released”. I think the better the developer, and the more conscientious, the more difficult this can be. We’ve all been grappling for years with the problem of developers over engineering anything and everything they can get their hands on! Knowing when to deliver the code, and being able to “let go” when the code functions as required are tricky skills to learn!

In my opinion, it has a fair bit to do with professionalism within the IT industry. Which perhaps brings the science back into Software Development. There will never be a “perfect” IT project, but with a better focus on the needs of the customer/business, and a higher degree of professionalism, I think many shortcomings can be overcome. However, client/business professionalism should also be considered, not simply that of the developers. No matter how professional a Software Developer becomes, if you are thrown a bunch of loose requirements, and the requested communication during the development phase isn’t forthcoming, then it should surprise no one when a poor result is achieved. As an example in a parallel field, when the head of the Hilton group decides to build a new hotel, he doesn’t throw the job at a couple of juniors, and ask them to deliver it in three weeks. Comprehending IT in business today, and it’s correct place within those same businesses is very important!
Software Development in and of itself doesn’t make any money. In the same way as a building in and of itself doesn’t mean people will pay to stay there. It’s how the business leverages the services associated that money is made. Understanding that IT is a service provider for the business is critical. Having said that, it is a service, but it is a critical component of businesses today, and needs to be considered as such.

As a new professionalism along with new tools and techniques are embraced by Software Developers, so too the business needs to utalise new procedures and patterns. Agile Development is great in theory, but requires excellent developers, and great clients in order to work effectively. High degrees of communication and excellence need to be worked on and maintained throughout the life cycle of the project.

Any organisation that deals with Emergency Services usually has some form of retrospective evaluation. While this seems to occur, at times with Software Development projects, all too often nothing substantial comes out of them. There is generally a culture of blaming clients, or blaming the developers when anything goes wrong, and “Lessons Learned” are rarely evaluated and even more rarely acted upon.

Software Developers need to know when to let go, when they’ve done “enough”. Conversely the business needs to understand development and it’s place within businesses. It will only be by repeatedly doing, and creating habit, that we can improve our teams, and the results they produce. Striving for Excellence is not something software developers, project managers and even the IT industry as a whole can do alone.