3 Tips for Getting that Large Project Going

Introduction

In the past, I have had a hard time getting large projects off the ground. I kept thinking about all of the technical details, which libraries and languages I will use, and how successful the project will be once it is finished.

The problem is, I never started on the work. Every time I got 20 minutes or an hour to work on it, all I could think about were these technical details.

I have long since learned from my mistakes and have found 3 general processes for getting large programming projects off the ground. If you're stuck in design mode, try giving these methods a shot:

Method 1 - Requirements Are The Key

Write only the generic requirements on a single sheet, in a binder on its own, or in a single document.

Keep the requirements short and sweet.

Keep all technical notes that you just can't stop thinking about elsewhere - they are not important in this phase. If possible, don't write them down at all. You will think of them later (or better ideas) and you don't want to force yourself into the wrong library later.

Think about how you will use this application/library, what will be difficult, what will be beneficial (again staying away from technical details including the language and library).

Begin writing code or manipulating wire frames as if you are using your newly completed project. Keep this "test code" for reference but don't make it the golden rule.

Collect flaws and focus areas and add them to a "things to consider" sheet.

Start writing simple implementation code starting at the easiest thing first (very similar to TDD but without the tests).

Success

I have used this method for some of my larger research type projects. It was very easy to adopt.

Failure

Three projects using this method never made it past this phase due to marketability and usability factors that were exposed. They seemed like fun research projects but were not practical so they remained a paper-only experiment.

Method 2 - Spike It

Maybe the best thing to do is a quick Spike (term from XP). Simply start writing a bunch of code you won't keep but will learn from. You get a feel for the project and end up writing version 2 first.

Success

I have used this successfully when picking up a modified version of the MVP pattern and some complex UI code.

Failure

I have kept the code written using this method due to time constraints. It has bitten me and was rewritten at a later date.

Warning

This works best for new requirements to existing systems. New projects also benefit as long as you are disciplined enough to toss the spike when you're finished with it.

Method 3 - TDD It To Death

This method is the hardest to master but one of the most powerful. Using Test Driven Development to work top-down (never TDD up) is very fun and productive.

First you starting at what you want to be the outcome (your initial requirements). Continue testing down until it is the implementation.

This takes practice especially when writing and maintaining the requirements list the TDD way. Refactoring and writing as little as possible while still adding value is also difficult when you've been writing legacy code for so long.

This method helps isolate dependencies so you can replace them easily if requirements change down the road.

Success

I have used this for a simple C# device interface project and a string template class. Both were to help learn TDD and both were never 100% completed. These projects had a lot of power, worked very well, and the code looked like a work of art.

Failure

This has failed just as many times as it succeeded for me. The reason was simply not knowing TDD, how to write requirements, and keeping myself from writing more code than I need to.

Summary

Start doing something NOW! Don't wait, think more, put it off... start doing something. Even failures are learning experiences. You cannot succeed if you don't try.

Good luck!

Test Driven Development in One Page or Less

Introduction

I was writing a co-worker to explain TDD. It ended up being a short and sweet guide to test driven development that I wish I had when learning TDD so I decided to share it. This is barely a starting point for TDD. I suggest reading "Test Driven: Practical TDD and Acceptance TDD for Java Developers" (even if you don't write in Java). Amazon.ca link here

If you would like a sample project for each step including tests, please leave a comment.

Development Environment

Refactoring support is crucial because you do it so often with TDD. When developing with Flex Builder (no refactoring other than rename), it was very painful and I caught myself skipping steps.

I prefer to use Visual Studio 2008 Professional (C#) + Resharper + NUnit.

NetBeans + JUnit works well and it's free.

I'm sure IntelliJ Idea is also a nice environment.

TDD In One Page

• You write out requirements in a certain way that makes producing tests from the requirement very easy. As you develop, you may think of new requirements (what if I pass in null?) so you add these to your list but don't start them right away unless they are the next best test to develop.
• Then you start with your test class and write your first test function.
• Then you instrument the class you intend to write before writing it.
• Since your tests are very basic and you start with the easiest one first, this should be short and sweet.
• Then you write the class with an empty method (just to pass compilation), and run your test. It should fail because you're probably not testing doing nothing.
• Then adjust the class in the simplest way possible that adds value. So for this one, we just want to make it pass. Return the expected value and viola! You're green.
• Now refactor (no need here - with this example)
• Continue with your next test
• This time you're looking at a different aspect of the same function. If we were making a function that returned string length, the first test may have been: when I pass in a null, I expect a NullPointerException. Now we may be expecting a 0 when an empty string is passed in.
• Run test (red - expected 0, got NullPointerException)
• So adjust the function to test for null & throw an exception, otherwise return 0. It still adds value because now we test for null.
• Run tests (green)
• Now refactor (no need here)
• Add a test for a single character string.
• Run tests (fails - expected 1, got 0)
• So adjust the function to return the string length rather than 0.
• Run tests (green)

As you can see, TDD is about Red, Green, Refactor, next test.

So What Do We Have Here?

At this point you have some great tests that stay with the project forever and didn't take long to write. Your code is clean and easy to use.

Without TDD, you may not have accounted for (or documented) what happens when you pass a null parameter into this function. We all get busy and working fast causes oversights such as this... ones that you will pay for later. *haunted house sounds*

More Complex Behaviors

If your function is more complex than this one, refactoring may bring pieces of the logic into private methods. These private methods still have test coverage which is why TDD is better than Unit Testing after the fact.

It could also become a new class. If so, you either pretend the class already exists (create a stub for now) or create the new class as if it were now the starting point and write tests for the new class first then integrate it back into your first class when finished. I prefer the 2nd method.

Your Implementation (not test code)

// first pass
int GetStringLength(string str)
{
throw new NullReferenceException();
}

// second pass
int GetStringLength(string str)
{
if (str == null)
{
throw new NullPointerException();
}

return 0;
}

// third pass
int GetStringLength(string str)
{
if (str == null)
{
throw new NullPointerException();
}

return str.Length;
}

When NOT to Unit Test

I may get some arguments here but TDD should be avoided when dealing with UI code. That said, Model, View, Presenter is a great pattern if you want to test the code directly behind the UI. Testing the front-end is not very productive unless you absolutely have to.

Finishing Up

Hope this helps at least one person figure out what TDD is all about. I found it to be faster to develop with because I wasn't troubleshooting bugs, my code was always clean, and I knew exactly what to do next.

Flex 3.4 Illegal override of FlexModuleFactory

An important note for those switching from Flex 3.2 to Flex 3.4

If you have css styles which were compiled (likely in FlexBuilder), you must re-compile them with the Flex 3.4 SDK to get rid of this error.

Line Causing Error

StyleManager.loadStyleDeclarations("yourexternalstyles.swf");

Exact Error Message

VerifyError: Error #1053: Illegal override of FlexModuleFactory in mx.core.FlexModuleFactory.

at global$init()

Help with "ref" and "out" in C# .NET 3.5 2008

In this article, I will discuss the out keyword and the ref keyword in C Sharp. These should be used sparingly but are handy in certain situations (especially when dealing with structs and sorting).

If you do not understand pointers yet, I would advise steering clear of these.

Similarities to other languages

Both "out" and "ref" mean pass the variable into the function "by reference".

If you are a VB6 guru, this is similar to the "ByRef" keyword.

If you're a C++ writer, you would use the address of operator "&" (if you did not already have a pointer to the object) and the function would have "*" following the data type.

There is no such modifier in Java.

What do they mean?

Out and ref extend the meaning of "by reference" by additionally stating that the variable must be initialized and will be modified (ref) or that it will be initialized inside of the function (out).

The default (no prefix to the parameter) is a "by value" copy of a structure/simple data type or a "read-only reference" of an object meaning you cannot change where it points to but you can change the variables inside of the class. This is how Java works.

The "ref" Parameter Modifier

• "ref" is by reference
• It does not give a compiler error if it was not passed in the argument list for the function
• It gives you the ability to modify the pointer of the original object
• It is a great way to pass structures around in code because it does not make a "by value" copy of them
• Parameter must be initialized before calling the function
• "ref" prefix exists when defining the function and when calling it (making it obvious that this is a by reference call)

Example of By-Reference Parameters in C#

public void SimpleSwap(ref String string1, ref String string2)
{

// store the pointer of string1
String temp = string1;

// set string1's pointer to point to string2
string1 = string2;

// set string2's pointer to point to string1 (HINT: this is not pointing to string2)
string2 = temp;
}

// ... code using this ...
String string1 = "ABC";
String string2 = "DEF";
SimpleSwap(ref string1, ref string2);

// string1 now points to "DEF"

// string2 now points to "ABC"

The "out" Parameter Modifier

• "out" is by reference
• The parameter must be assigned or you get a compile error
• A new object is created and returned (the variable you passed in points to the one created inside of the function)
• "out" parameters do not need to be initialized
• This is a great way to fill structures
• It allows the language to safely handle multiple return values without the need for new objects/structs
• "out" prefix exists when defining the function and when calling it (making it obvious that this variable will be initialized by the function call)

Example of a Function Returning Multiple Values in C#

public void GetCoordinates(out int x, out int y)
{

x = 5;

y = 9;

}

// ... code using this ...
int x;

int y;

GetCoordinates(x,y);
// x is now 5

// y is now 9

Conclusion

Out and ref are great tools when you need them. I hope this article helps you understand more about how they work.

Note: I use the terms "keyword", "modifier", and "prefix" when discussing ref and out. The actual term (AFAIK) for these is "modifier".

Note: Code examples in this article are incomplete and will not compile. If you require complete examples, please leave a comment and I will post them for everyone.