Derik Whittaker : Opinion, Methodology

Removing words like Convince, Convert and Persuade from our vocabulary

Derik Whittaker — Tue, 04 Nov 2008 11:26:22 GMT

One of the common themes of this years KaizenConf was how to move a towards being a lean organization. During most of the sessions and conversations that I was part I cannot tell you how often I heard words like Convince, Convert and Persuade said. At first I had nothing against these words, but the more I thought about I know feel that we need to remove those words from our vocabulary when talking about moving a team or organization from one thing to another (in context of these conversations it is towards being lean).

Using terms like Convince and Convert has the feeling that 'I am right and you are wrong'. Even if you are not using terms like Convince and Convert in your dialog with people, I am going to guess that you have that as your goal, or your end game.

I am here to suggest that we as a community need to change our focus from Convincing towards Demonstrating. By changing our angle and our position to be more neutral and soft I feel we can archive our goal of bringing change easier and with less friction. It is like that old saying 'you can catch more fly's with honey than vinegar.

Lets take a look at the subtle differences between Convincing and Demostrating.

When we are trying to Convince someone of something many times we give off the following vibes.

That your way is wrong, and our is right
That we are better and more knowledgeable
That we are preaching

All of above tend to put people on the definsive and if someone is on the definsive they are less likely to be open minded and less likey to want to try to understand what it is you are trying to say.

When we are trying to demostrate something to someone we give off the following vibes.

Heartflet attempt to share knowledge
Cooperation
Alternative to, not a replacement for their way of doing something
Sincere intrest in helping them.

When you speak to someone with the above vibe, you are essentally telling them that I have an idea and I think that my idea can help you out. If you attack it from this angle you may be surprised by the level of reception you can receive.

Remember, convincing someone is never easy, but demostrating alternatives and allowing them to make their own decision can be.

Keep up the good fight and happy demostrating.

Till next time,

Unused code is the worst of the 7 Wastes of Software

Derik Whittaker — Wed, 06 Aug 2008 21:21:44 GMT

Today I was having another round of conversations with a buddy of mine about the concept of waste and unused code.

In agile there is a concept called YAGNI (You Ain't Gonna Need It) that basically states that you should not add code that is not immediately needed as it is waste.

In Lean software this is known as one of the 7 Wastes of Software. To quote from 'Implementing Lean Software Development'

'The worst of the seven wastes of software development is adding features (read that as simply code) that are not needed to get the customers' current job done.'

The context of our conversation was around code generation. Now I am NOT a huge fan of CodeGen as I have been on the wrong side of a project that used CodeGen. What we were debating was if it was just better to CodeGen up all the CRUD logic (they are using data driven design, not a domain driven approach) prior to needing it or create it as you need it.

The conversation started with this statement from my buddy.

'If I had to go stub a select out for a table, I'd be like WTF. Whoever created this app sucks, they did not even create select procs for me'

When he made this statement I knew I was in for a uphill battle, but I tried to convey my thoughts. However, at the end of the conversation we agreed to disagree (but he is still wrong :)) and we went back to our neutral corners.

So, what are my thoughts on why unused code is waste:

You are creating speculative code for a need that you may or may not ever realize. And my experience tells me more often then not that code will not be needed.
There is now more code to be maintained (in his case I have to modify/regen code if my db tables change) which leads to more work in the long run.
There is now more code to test, which means more tests to fix/refactor when that code changes.
There is now more code to refactor if you change directions later, and we all know you will change directions.
Your needs may/will change between the time you originally wrote the code and the time you needed it.

The only real responses he could make were:

Since this code is created via CodeGen, who cares if it changes I can ReGen it.
My response - This is a weak excuse as re-creating massive amounts of code is expensive and time consuming. Also not mention everyone on the team may not necessarily know/understand how to do the CodeGen
I do not want to take time later to build the functionality out as I need it. Especially when it comes to things like CRUD proc.
My response - This is about the lamest excuse ever. Creating the functionality as needed, when needed, is the ONLY want to correctly solve your business problem.

So, what lesson have learned here today. Unused code is waste and there is no 2 ways about it.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Defensive Coding best practice

Derik Whittaker — Tue, 22 Jan 2008 13:05:00 GMT

<disclaimer>
This posting is purely my personal opinion. I am sure many of you out there will disagree, if this is the case, let me know.
</disclaimer>

Today, during my bug hunting I stumbled across the dreaded 'Null reference' exception. This was not the original target of my hunt, but it quickly became wanted bug number one. After some digging and debugging I found the the varmint. The offending code was the following a null ref because someone made the mistake of assuming that an object would always be non-null.

listMain.Items.FindByText( listChild.SelectedItem.Text.Substring( 0, 1 ) ).Selected = true;

Now let me explain the intent of this code. There are 2 list boxes on the UI and when someone selects something in the second list box, the code is meant to filter down the code in the first list box. However, the code above assumes that there will be a match for the 'FindByText' method and this is where we have problems. The author of this code decided that there will NEVER be a situation where the filter will not find a result. Oops.

The defensive coder would not make that assumption and would have added a few extra lines of code. Below may be an example:

ListItem foundItem = listMain.Items.FindByText( listChild.SelectedItem.Text.Substring( 0, 1 ).ToUpper() );

if ( foundItem != null )
{
	foundItem.Selected = true;

	// Do something with the result	
} 
else 
{
	// Do something, either tell the user there was no data or anything else the business wants
}

By adding the defensive code we can avoid the 'Null Reference' exceptions that we all love. We also make our code more robust by forcing the developer to thing about possible exception conditions.

For more information about Defensive Coding, check out this link here.

Till next time,

Failing builds, the sound of silence

Derik Whittaker — Wed, 07 Nov 2007 13:00:48 GMT

I'm sure that everyone has heard the riddle 'If a tree falls in a forest and no one is around to hear it, does it make a sound?'. This riddle is all about observation and knowledge of reality.

Well, I have a riddle for software teams following TDD.

'If a build fails and no-one fixes it, did it actually fail?'

Till next time,

Subclassing for Success

Derik Whittaker — Fri, 02 Nov 2007 12:36:58 GMT

As someone how has been designing and developing WinForms based applications for the past 7+ years, I have learned that subclassing UI controls is a must. You may be thinking, why would I want to subclass a text box? Or a combo box? The answer is simple, the better future proof your app.

How many times have you been into the development cycle of your application and you found out that you needed/wanted to extend the text box that is being used. By extend I am not necessary talking about adding functionality to it, but do something like having the control highlight the entire contents of the control when the it receives focus.

If you don't have your controls subclassed, extending your control will be a pain in your ass. Sure you could find EVERY use of the control and add the needed code. Or you could find and replace your control later with the subclassed control, but both of these suck.

When I start a new WinForms (same concept should work for Browser based as well) application, I will immediately add a Controls namespace and simply add my subclassed controls. In many cases I never extend the control, but knowing that I can do so allows me to make better decisions later on.

One example of where this has helped me in the past was on a project where about 6 months into development, the business owners decided that would like the UI controls (text box, check box, combo box, etc) to change background color when the control receives focus and then change back when it loses focus. Because I had everything subclassed i was able to implement this request in a very short time frame and did not even have to open up a single form. Had I not subclasses the controls I would have either pushed back heavily or it would have taken me much longer to implement this change.

Another good use is for things like data grids. Whether you are using the out of the box data grid, or some third party grid like Infragistics or Janus, subclassing can save you a ton. How many times have you developed an application where you wanted a standard look and feel for your grids. Say every other line is gray, and there are no selection column. If the control is not subclassed you are asking each developer to remember to make the look and feel customizations. But, if it is subclassed, simply add the control to the form and you are done.

Till next time,

Backing in Unit Tests into an existing project

Derik Whittaker — Tue, 09 Oct 2007 12:35:39 GMT

Recently I was asked about backing in unit tests into an existing project. In particular I was asked A) was possible and B) is it worth it. In short my answers to both these are Yes and Yes. However, backing in unit tests is not without its challenges. I thought today I would go express my experiences with doing exactly this and what types of hurdles I ran into.

Start off by only testing new code
When backing in tests, it is very important to accept the fact that a large percentage of your application is going to be untested. Accepting this fact will help you move forward. I would suggest that as you write new code (be it new modules, features or whatever) you write them following the TDD practice. This will be the simplest way to get the ball rolling.

Doing this is also an easy way to get other team members on board with the testing idea. I know from personal experience that when we wanted to started following TDD on a project that was 2 years in, many of the other developers thought it was a waste because we have so much that is untested. They thought it would take too much time/effort to write test for existing code. I agree with this. So only test going forward

Add tests to existing code only when changes are needed
I know I just said above to only test new code, and this is true. However, when you are making changes to existing code test those changes. Again, you don't have to try to test all the existing code, only the path ways you are adding/changing.

If you follow this, over time you will start to build a nice suite of tests that tests not only new code, but some existing code as well.

Mock as much as possible
Mocking is a great tool. I like to mock code that I don't have control over, or when I have no faith the code will work reliably. This is especially important in a project that does not have tests.

An example would be this. Lets say you are adding a new feature to an application that needs to call into some sort of calculation engine. Since this calculation engine is not tested and you have no real faith that it will work reliably, mock it. You should know that given a valid set of inputs you expect to receive a given response. By mocking this you remove all risk of the calculation engine failing thus causing your tests to fail.

*** I can hear you now, you want your test to fail when the calculation engine fails.... No you don't. Unless your test is actually testing the calculation engine, you don't care if it passes or fails. You just need to call it. ***

Take this as a learning experience
Take this time as a way to learn to write good solid tests. This will be of great benefit later in your next project. Also, you will also learn how to write better code that is more acceptable to testing (hum... sounds like another good post). Remember, in order to become good at something you must first be bad at it. But with practice you will become better and you will be a better developer because of it.

Be patient
Testing is painful at first. It is a shift in your development mind set. Be patient, it gets better. This is no different then learning anything else. It will take time, but eventually you will become comfortable with TDD and it will become second nature. You never know, you may end up like me and find it odd when you are NOT writing tests.

I hope this helps.

Till next time,

Why I believe IN and WRITE unit tests

Derik Whittaker — Tue, 02 Oct 2007 00:27:25 GMT

In my last post I think I struck a cord with some people in my post 'Unit tests taking too much time'. My intent was NOT to sound like an elitist Agilist or any else of that nature. My intent was simply to put a post out there about the misperception (in my opinion) about how writing unit tests take too much time.

I thought I would put my 'retort' on why I believe in and write unit tests.

Allows ME to write better code

I believe that when I truly follow TDD practices my code comes out simpler. I have also found, that my code tends to follow YAGNI more so then when I don't follow TDD practices.

Here is an example from my past experience. On a prior project I needed to build a 'search engine' into our app (this was not an actual search engine, more like a hunt path engine). When I first started out writing code I started out by creating all these classes and logic that I thought I would need. After about 3-4 hours of coding I was dead in the water. I was not able to solve my problem in a simple manner and I was frustrated. I decided to take a step back and start over.

This time though I started out by writing test to mimic what I actually needed. I continued to follow the principles of TDD (btw, TDD is more then just about writing tests), within an hour or so I had my solution pretty much good to go. All those classes and methods I THOUGHT I would need I did NOT. I was able to scrap about 50% of the code/classes that I thought I needed. And guess what, now I have a test suit to test my new code.

Allows ME to find more bugs during the development process

It has been my experience that I find more bugs while writing tests. This is due to the fact that I not only follow TDD, but I also do my best to implement the Fail Fast Principle. When I am writing my tests I have the ability to create tests that easily walk though the different pathways of my code (I attempt to hit 100% code coverage as well). If I were not writing tests I would have to do this via the application, and this is much more painful and it less likely that I would actually do it.

By writing my tests and testing my code during the development process I know that I have reduced my bug count significantly.

Makes ME feel more comfortable making changes

This is the beauty of TDD, I am not afraid to make any critical changes to my code because I KNOW that I have tests to verify if I screwed anything up.

Have you ever run across some code that 'you were scared' to change? If you had tests for that code I bet you would a WHOLE LOT LESS scared to make any changes. I know that I am.

A case in point for this is as follows. On a prior project a consultant I was working with needed to make changes to some 'smelly' logic. This just happened to be a week or so before a scheduled release. Beacuse he had NO confidence that the changes he would make would NOT break the application, he convinced the business to NOT make the changes. I bet you a dollar that had there been unit tests he would have been much more willing to make the changes. In this case the fact of NOT having tests may have caused the business to lose out on features it needed.

Improves MY code

Because following TDD practices forces you to write your failing code before your passing code, I tend to implement my intent much cleaner and simpler. I also know that because I am writing tests along the way my code is solid.

Allows ME to better convey intent

I know that tests are not a substitution for quality comments that convey intent, but they sure are the next best thing. It is really nice to be able to point someone towards a suite of tests to 'demo' how to use a component.

A case in point for this is as follows. A few weeks ago at work I wrote an API to allow the querying of some data via our imaging system at work. Turns out that an outside party needed to use this API for integration into on of our 3rd party applications. When he came to me asking for 'how do I use this', I simply emailed him my suite of tests. In this suite I had pretty much any conceivable use for the API. To date the vendor has not asked me how to implement the API.

Allows MY tests to be automated and rerunable

This is a nice side effect of having tests. Because we use both NUnit and CruiseControl I can run my tests on every check in. This is cool because now I (and the team) know if changes I made breaks some other part of the system. I would rather know now then before QA hits it.

The above are simply my opinion, if you don't share the same opinions, let me know.

Till next time,

Standard questions to be asked when logging bugs

Derik Whittaker — Tue, 21 Aug 2007 12:51:00 GMT

In my last post (here) I spoke about different do’s and don’ts when it comes to logging bugs. What I really did not hit on was the different types of questions I feel should be asked when logging bugs.

Here are my questions, in no particular order.

Platform
Application Version #
Environment
Title
Short Description
Details Steps
Data used during testing
Module/Sub Subsystem (if applicable)
Is Reproducible
Screen Shot (if applicable)
Attachments ( if applicable)

The above is the list of data I think is valuable in order to property address and fix bugs.

Did I miss any?

Till next time,

Logging Bugs: Do's and Don'ts

Derik Whittaker — Mon, 20 Aug 2007 00:40:00 GMT

All software that is being developed WILL have bugs, sorry, but this IS a fact. Now I know some people and companies don't like to call them glitches in software bugs. They would rather call them issues or defects. For all I care we can call them 'WizBangs', just call them something and LOG THEM.

However, logging 'WizBangs' (ok, I will call them bugs from here on) is not as simple as it may sound. I would like to go over some of MY Do's and Don'ts in this post. If you don't like my list, or would like to add to it, drop me a line.

When to log Items:

Do log everything. Just because the bug may seem trivial or simple or only happen 'every now and again' does not mean that it should be ignored. Even it you are not sure it is an issue, LOG IT. Better to have close off an non-issue then fail to report a major bug in hiding
Don't assume that someone else is going to fix the issue. Also, don't assume this issue is too trivial or minor to report. Wouldn't it suck to find out after the application went lived that you failed to report a critical bug because you thought it was not a 'big deal'?

Providing information on the log:

Do provide detailed information about the bug. Save yourself the headache later and provide as much information as you possible can. This should include, but not limited to items such as Build Version, Environment, Platform, Short Description of issue, Severity, Detailed steps to reproduce.
Don't make provide a single sentence that says something like 'Unable to perform XYZ in the ABC process'. This type of information will provide nothing of real value to the next guy. Sure, this would be a great line for the title of the bug. But by no means is this enough information to fix the bug.

What types of items to log:

Do Log Everything. Enough said
Don't make assumptions

When to log bugs:

Do log them as soon as possible.
Don't put it off. If you dont log the bug as soon as you find it you WILL forget something about what you did to cause it. For the sake of your fellow co-workers log it now before you forget.

The plain and simple truth about logging bugs is, it sucks!!!! However, it is a necessary part of most developers jobs. If you take some time and put in a little effort, you will be rewarded with great riches. Ok, maybe not great riches, but it will make fixing the bugs much easier.

Till next time,

Switch Statements with Enums best practice

Derik Whittaker — Tue, 26 Jun 2007 12:08:00 GMT

Over the years I have come to the conclusion when working with switch statements that switches on enum values, a DEFAULT block MUST be required. Not only should it be required, I think it should throw a developer exception. *** NOTE *** My stance on this...(read more)