• Unit test on the real device or emulator using the real android framework
• Unit test on our PC using the JVM

Each choice has some pros and cons, but for me it came down to the speed and flexibility allowed by running in a real JVM.  I actually tried to create an Android unit testing project using the scaffolding provided by Google but it turned out to be very restrictive, especially since I couldn’t use JMock.

There is also something to be said for being able to execute the unit tests extremely quickly.  If you have to wait for an emulator to come up, or try to run them on a real device, it is less likely the unit tests will be run.

How to do it

The basic idea of this approach is fairly simple.

We are going to try and abstract away any Android specific calls from our application and then unit test the plain Java logic in the application just like we would any other Java project.

Step 1:  Create a JUnit project

Create a new JUnit project just like you would for unit testing any Java application.

Make sure you chose Java Project rather than Android Test Project.

From here you can add your JUnit references to your build path.  I would also recommend adding Instinct for doing BDD style testing.  Instinct uses JMock internally to create mocks for you using a declarative approach.

The only other thing you will want to do with this project is to add the android.jar to the build path.  The android.jar can be found in your Android SDK directory under the platform directory that corresponds to the API version you are targeting with your application.

For example, on my machine, I am targeting Android 1.6, so my android.jar is at:  C:\Android\android-sdk-windows\platforms\android-4.

Now remember, you are including the android.jar in the project only so your classes can understand what types exist in the Android framework.  If you even try to call a constructor on a class in android.jar, you will get an exception.

Step 2: Pull all the code you can out of the Activity.

The next thing we need to do is clean up our Activity class to make sure that it has the smallest amount of logic in it as possible.

Since we can’t actually instantiate any types that exist in the Android framework, we are not going to be able to create an instance of our Activity in the test project.  So we are not going to be able to unit test our Activity.  This isn’t a problem if most of the logic we care about testing exists in other layers in our system.

You can design the lower layers however you want.  I am still not quite sure the best approach here, but what I did was put a presentation layer directly below the Activity.  I have a Presenter class directly below the Activity that tells my activity what to do.  The Activity passes on any interesting events or information to the Presenter.

You should leave the Activity with the responsibility of setting the text on its own view objects, but create methods for your lower layers to tell the Activity what text to set the objects to and so forth.  Activity is going to act as an adapter to a large portion of the Android framework for your application.

Because the entrance point into your application is going to be the Activity, you will need to wire up the rest of your layers from the Activity.  This is a little strange, but it works.  In my application, I create a new Presenter and pass this into it on the constructor.

When you are done, your Activity should look pretty thin.  It should delegate all its event handler logic down to the lower layers and act as a pass through for manipulating the view.

Step 3: Wrap remaining Android object calls.

You’re going to find that some of the remaining Android API will need to be called from lower down than the Activity.  This is not as big of a problem as it seems.

In my application I needed to make some calls to android.os.SystemClock.  I needed to make those calls lower down than the activity because it is part of the heart of the logic of my application.

I created a simple SystemClockWrapper class that wraps system clock and delegates any calls to the real SystemClock class.  Then I extracted an interface from that class called ISystemClock (hey, I like the C# convention for interfaces.)

Finally, in my application logic, I allowed the ISystemClock reference to be passed in or “injected” through the constructor of the class that used it.

public class SystemClockWrapper implements ISystemClock
{
     public long getElapsedRealTime()
     {
          return SystemClock.elapsedRealtime();
     }

}

public interface ISystemClock
{
     public abstract long getElapsedRealTime();

}

In my unit test I just pass in a mock version of the ISystemClock interface.

One hint here is to use the refactor tool in your IDE to extract an interface.  This can save you some time of trying to manually create interfaces for large pieces of functionality you are wrapping.

Putting it all together

Now you should be able to create your unit tests against most of your application logic and run them just like any other unit test project.

The only thing you won’t be able to do is unit test the logic in your Activity classes.  This shouldn’t be much of a problem if you have made them into views, because they should only contain view logic.

If you really want to be able to write some tests for the Activity though, you can create another actual Android Test Project and use Google’s framework to write unit tests from there.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

In the course of building this app, in a previous post I mentioned that I wanted to find the right, or perfect way, to build an Android application.

I haven’t found the best way to build an Android application into a nice clean design pattern, but have found a way that seems to work, and makes the application testable and easy to maintain.

I do believe though, that I have found the optimal way to do unit testing in Android right now.  Yes, a bold statement, but I have looked high and low for a better solution, and can’t find one.

The problems

So first a little bit of background on the problem with unit testing in Android.  Take what I say with a grain of salt here, because I am not an Android platform expert, and feel free to correct me if I misstate something.

Android.jar

If you download the Android SDK from google, you will find that the android.jar you get with the SDK is much like a C++ header file; it doesn’t actually contain any working code.  As a matter of fact, all the methods are stubbed out to throw an exception with the message “Stub!” when you call them.  How cute.

The real android.jar implementations live on the emulator, or your real Android device.  So, if you want to actually run any code that is going to call any methods or try to construct real Android framework classes, you must run that code inside the emulator or a real device.

Dalvik VM

When you’re working with Android, it sure feels like you are writing regular old standard Java SE code, but you are not. You probably won’t notice the difference, as almost everything that you need is there in the Dalvik VM implementation of Java.

Dalvik is not even a Java Virtual Machine at all.  That is right, it runs on cross-complied .class files which are converted to a .dex format.  Yes, is does not use java byte code.

Why do I mention all this?  Because you might want to use something like JMock to mock your dependencies when writing your unit tests.

Well, you can’t.  It just isn’t going to work, because the Dalvik VM doesn’t use java byte code, so the reflective coolness that mocking frameworks like JMock use doesn’t work the same.

Be aware that any external library you try to use in your Android project may not work because Android does not support the full Java SE implementation.  It actually is a subset of the Apache Harmony Java implementation.

There is no main()

Where does an Android application start running?  From the activity.  Which is basically the view.  (Some people will argue this is the controller or presenter.  And yes, I agree in respect to the Android framework it is, but in regard to your application framework it is the view.)

Android applications define a starting activity and launch from there.  Activities can even be launched from other applications.

This tends to disrupt most of our MVC, MVP, MVVP pattern architectures, as the view is going to be the entry point and will have to be responsible for initializing the rest of the application.  (That is not entirely true, as there is an android.app.Application class that gets called the first time your app is run, to launch the main activity, but for the most part you can’t do much here.)

Essentially though, you have to build your architecture based on each Activity being its own separate little application, with the entry point being in the activity.  This puts some serious constraints on unit testing.

Putting it all together

So if I can sum up the problems briefly, I would say:

• Android framework code has to run in the emulator or on a device.
• Dalvik VM doesn’t allow us to use our standard mocking frameworks.
• Entry points for our applications are in the views.

The first problem, combined with the second, lead us to an interesting choice.  Should we run our unit tests on an actual emulator or device using the Dalvik VM, or should we run them in a JVM?

It is probably not an obvious question, but let me explain why it is the most relevant.

In writing an application, we are going to have application logic that has nothing specifically to do with the Android platform, and we are going to have Android platform specific logic (drawing views, handling Android OS events, interacting with Android APIs etc.)

If we want to write true unit tests, we need to isolate our classes and test them individually.  We should be able to do this for our application logic, without relying on the Android framework.  If we don’t rely on the Android framework, we don’t need to run on a real or emulated device, thus we are not constrained to the Dalvik VM.

If we choose to run our unit test code on a real or emulated device:

• We will be able to use the Android framework APIs in our testing efforts.  For example, we can create new location objects instead of mocking them up.
• We will be completely true to the real execution of our code.  Since we will be using the real VM the code will run on.
• Since we are running our tests on a device or emulator, they will run much slower.
• We won’t be able to use JMock, EasyMock, or Mockito, we’ll either have to roll our own mocks or use a fledgling Android mocking framework.

If we chose to run our unit test code in a JVM on our PC:

• We will have the full power of the JVM available to our test code, so we can use mocking frameworks like JMock, and BDD frameworks like Instinct.
• We will run our unit tests much faster, since they will be using our PC instead of a device.
• We can use standard unit testing practices and not have to inherit from special Android classes, or use special Android test runners.
• We will have to wrap any calls to the actual Android framework if we need to use any Android classes or services deeper down in our application.
• We have a small risk of having different behavior between running the tests and the real application, because we will be running the code on different VMs.

In my next post, I’ll detail which option I chose and why and also give some detailed steps of how to get setup and running.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

That was about 3-4 years ago.

I just wrote some code to do it again, and well…  It still sucks.

Perhaps I’m doing it wrong, but if you are looking for, “how to implement paging in sql server”, or “how to page sql server stored procedure results”, or “paging sql server”, I’ll give you my best answer for it at this point.

(Google search term additions above for helping people find help)

How I roll with CTEs

CTEs or Common Table Expressions, are a pretty nice feature of SQL Server.  They are a bit complex, but basically they let you create a query and treat it as a table to select from.  They also allow recursive calls to themselves, which let you do cool things like query hierarchies of data.

This link offers a pretty good explanation of CTEs.

Anyway, CTEs come in handy combined with the ROW_NUMBER() function to add the ability to page data from an existing stored procedure.

The basic idea here is to modify the original query by wrapping it inside of a CTE that adds a RowNumber column.

Then we can select from that query the rows that are in the range we want.

Vegetables are good for you

Let’s look at an example:

SELECT name, goodnessfactor, color
FROM vegetables
WHERE color = 'purple' OR color = 'green'

Now let’s modify this query to be pageable given we have the first and last record we want.  (first record = page number * rows per page, last record = page number + 1 * rows per page)

WITH pagedVegetables AS (
    SELECT name, goodnessfactor, color,
    ROW_NUMBER() OVER (ORDER BY name) AS rownumber
    FROM vegetables
    WHERE color = 'purple' OR color='green'
)
SELECT *
FROM pagedVegetables
WHERE rownumber > @firstRecord AND
               rownumber <= @lastRecord

Okay, so it is actually not that bad.

A couple of notes to help understand what happened here.

• ROW_NUMBER() requires an OVER clause which basically will determine how you calculate what the row number is.  In this case, we are going to sort by name.  So the first alphabetical name will be row number 1, and so on.
• We’ve wrapped the query in a CTE, and added an additional column so that we have a row number in our new virtual table.  (Think of the CTE as creating a temporary view for us.)
• We are selecting everything out of the original query that is in the range of rows we want.  (Depending on how you define your range you may use different equality operators.  If you range is inclusive, you would do <= and >= , and if it is exclusive it would be < and >.  In this case we are both.)

A word on total row count

If you need the total number of rows, so that you can pass that back to the pager in your code, then you will probably have to select the results from the CTE into a temporary table and return two result sets from it.

I couldn’t really find a way to select the total rows and the data from a single CTE expression.  If you know a way, please let me know.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Some of your coworkers probably don’t struggle with the issue because they really just don’t think about it that much.

But, if you are reading this blog, you probably have encountered the problem I am about to talk about.  It may be for you, like it is for me, the single greatest thing holding you back.

What am I talking about?

The struggle with perfection

We want to build perfect software, we want to build perfect code, but it is just not possible.

Like Tyler Duren’s alter ego, we want to put everything in a nice little box.

I had mentioned earlier that not all software developers struggle with this problem.  I think it arises when you start to actively seek to improve your development skills.  It is natural to look for the “right” way to do something you want to get better at.

• There is a right way to swing a baseball bat.
• There is a right way to do mathematical calculations.
• You can play a piece of music perfectly on a piano.

But there isn’t a right way to build software.

There are lots of wrong ways, and then there are many better ways that all have trade-offs against each other.

It is vey hard to come to grips with this reality.  At least for me it is.  I want to know how am I supposed to do it, and I don’t want to hear “any way you like”, or “however seems right to you.”

Software development is part craft

There is some science to it.  Don’t get me wrong.

The biggest problem in software development is not people struggling with perfection, but rather developers believing that there are no wrong ways to develop software.

You can learn what is right to some degree, up to a point.  But, after you steer away from the obviously wrong, you end up drifting into the true craft of software development.

When you only have one tool, software development is easy.  You just hack on things with your one tool.  You might not be very effective, or very efficient, and you may make a pretty big mess, but you generally can get things done and you know what to do.

When you have a toolbox full of tools, the world stops being so black and white.  Software development truly becomes an art or craft at this point, as you are forced to make trade-offs and choose architectures and technologies based on experience and intuition combined.

Our minds fight against this concept of unrule.  It is like playing monopoly with generalizations or ideas of how the game should be played, but no explicit rules.  Sometimes life is just easier within preset boundaries that clearly tell us what is right and what is wrong.

It is a strange twist of fate that the act of building something that is absolutely structured and governed by rules is such a rule-less and judgment based pursuit.

Dealing with perfection in an imperfect world

So why is striving for perfection bad anyway?

Well, it can be a major roadblock that prevents us from getting things done.

I’ll often find myself at the 90% better than I started solution, and pushing to get to 95%.  That push to 95% can take the same amount of time it took to get to 90%.

Sometimes when we are looking for the perfect architecture, or trying to apply patterns, because we believe they are right, we end up making things more complicated than they need to be, or we miss a better “less perfect” solution, because we have deemed it so.

One thing I have tried to do to curb my insatiable desire for perfection is to strive to always improve rather than for perfection itself.

It is important for us to recognize when we are at that 90% mark and move on.

Next time we encounter a similar situation, we’ll hit the 91% mark, because we will have more experience and will have built better intuition.

Here are some tips and strategies I have picked up for dealing with the problem of perfection.

• Try to get rid of the all or nothing mentality.  Don’t do things just good enough to get by, but don’t try to do them perfectly either.  Do an excellent job, and know what that is.
• Start working on things in a rough draft form.  Fill in details later.  This especially helpful with web pages or anything that requires design work.
• Don’t get stuck on a problem that is mainly just polish.  If the elegant way to do something is causing you 10 hours of debugging, but you can do it in a less elegant way and hide the mess in a nice package, opt for the second.  You can always come back later, when you don’t feel pressured to find a solution.
• Get a second opinion.  If you are struggling with a design issue and going back and forth in your head about the best way to do something, ask someone else and it might make one way or another perfectly clear.
• Make yourself a research note.  Move on for now, and make a note to come back later or to research a technology or design.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

“Hey, how do I test out our web app?”

“Oh modify your hosts file so that when you go to wonkywares.com it goes to test.wonkwares.com.”

“Umm… ok, that sounds great.”

What this is doing

What I am talking about is going to C:\windows\system32\drivers\etc\hosts and adding entries to that file that map ip addresses to host names.

The hosts file is basically a mapping for ip addresses to host names.

So if you put an entry,

207.46.0.87 google.com

in the file, when you type google.com into your browser you will go to bing.com instead. (That is the ip address for bing.com.)

Why would someone do this?

Well if you have some code, automated scripts, or process that uses your real production domain name, you can modify your hosts file so that the production host name gets resolved to the test ip address.

Magically, when you go to wonkywares.com you will instead go to test.wonkywares.com.

Yes, I do realize this may seem cool and clever.

Heck, you might have stopped reading this blog and called an emergency meeting so you can tell everyone on your team how they can modify their hosts file to magically make your production scripts work on test without passing in the url.

What could possibly go wrong?

Let me give you a scenario:

“Okay Jeff, I’m gonna run the tests scripts on my new workstation to make sure everything is still working right.

“Joebob, how do those fancy dandy test scripts of yours work again?”

“Well Jeff, they drop all the data in the tests database and then create new test data, run the tests, and clean up the data after them again.”

… Joebob runs the test scripts, and watches as they all pass, thinking about how awesome and clever he is.

RING… RING… RING…

“Hello, this is Joebob.”

“Hi Joebob, this is the CEO, Mr. Wonky, I am getting reports that there are no products at all being displayed on our production website.”

“Oh shnikies!  I must have forgotten to modify my hosts file to point wonkywares.com to test.wonkywares.com.  I ran my test scripts against production.”

… Joebob pulls a wonkywares revolver out of his bottom drawer, right next to the single malt scotch he keeps for “planning day.”

I am sure you can guess what happens next.

Let me list for you some of the bad things that can happen if you modify your host file to be clever, instead of parameterizing your scripts or code to be able to take a configurable url.

• You run your test scripts against production because you forgot to configure your hosts file on your new machine.
• You think you modified some production data for a data-fix, but you actually only modified test data.
• Someone else uses your machine and doesn’t know that you have a modified host file.
• You use someone else’s machine and forget they don’t have a modified hosts file, so you think you are going to the test website, but you are really modifying live production data.
• Your IT guys switch the IP addresses of the staging and production server as part of a rotation so they can do maintenance work on what was the production hardware.  You now are pointing to production instead of staging and have no clue.
• Someone else tries to run your script or code and is not aware that they have to modify their hosts file first.  They run your scripts against production.
• You change your hosts file and expect the change to immediately take effect, but your browser is smart and has cached the ip address of the page you just visited.

I am sure you can think of plenty more reasons.

So instead of being “clever” and modifying your hosts file, try making whatever code you are writing take in a parameter for the url to use, or read it from a configuration file.

Well, I was having my head rearranged by JQuery.  I have to admit, I am pretty late to the party.  I haven’t really been using JQuery at all the past few years.

I missed a lot.

Goodbye type safety

This part scares me a little bit.  I already made a few typos that were pretty hard to detect.

Debugging javascript is not much fun considering that data and methods are both first class citizens.

But, the trade-off just might be worth it.

What we are losing in type safety, we are making up for in productivity and speed.  It is really fast to manipulate a page using JQuery and to hook up events.

I still wish there was some way to have some sort of type safety when using JQuery or Javascript in general, but it really hurts my brain to try and think about how that would be possible.

Perhaps some kind of Script# / JQuery bastard child?

I know some people are doing Javascript unit testing.  That would certainly make me feel safer not having type safety.

Functional thinking

I like the functional thinking paradigm.  One of my co-workers was saying that he likes JQuery because it helps him to write Lamba expressions and LINQ queries.  I tend to agree with him.

I’ve said it before, but I believe the next high abstraction of programming is thinking functionally.

So many pieces of code that I would have used code generation to produce in the past, I can now produce with Lambda expressions.

It’s not all roses

I do have some major issues with JQuery and Javascript in general.  One of the big problems is that JQuery is not a language, and it’s not a library.  It is a DSL built on top of a language.

Bleeding all the way through the stack

The downfall of this is that it is a very leaky abstraction.  Abstractions are good because they allow us to think at a higher level.

Leaky abstractions are bad because they force us to context switch from a higher level of thinking down to a lower level.

In order to understand JQuery you must understand Javascript, the DOM and CSS to some extent.

Think for a second about all the “languages” or technologies you have to know to develop an ASP.NET web page using JQuery and MVC.

• ASP.NET MVC
• HTML
• C# or Visual Basic
• JSON
• Javascript
• JQuery
• CSS
• Web Services / Rest
• HTTP (You need to be able to debug all the coolness you are flinging back and forth.)

When you have it all working, it is pretty slick.  Very slick indeed, but it is not a sustainable model.  It is complex and sprinkled with errors and gotchas.

Debugging / readability

When I am writing JQuery, although I feel like it is magical and cool, I also feel a little bit dirty.

Why?

Well, as clean as you try to write JQuery code, it can be pretty nasty.  There is a lot of magic going on, and it is not very easily understandable.

Perhaps I’ll get better at expressing my intent clearly in JQuery code, but I am pretty sure it has to due in part with the leakiness of the abstraction layer, and that can’t really be cleaned up easily.

Debugging is also hell.  I tried debugging through the validation library to see why my error messages weren’t showing up, and it was no picnic.

Javascript itself is notoriously difficult to debug, because objects can have methods dynamically added to them, and all the other little tricks, make it hard to look at a watch window and get anything useful out of an object.

View logic

One of the things I really enjoyed while writing JQuery code was putting the view logic where it really belongs.  It is nice to have a language and a server separating the view logic from the model and presentation.

JQuery really allows you to put all the code that manipulates the view in one place, and on the client side, where it really belongs.

JQuery will make your HTML code so much cleaner and helps to actually plug the leaks in the HTML abstraction layer.  (Although it isn’t perfect, especially when working with ASP.NET Web Forms.)

Better late then never at all

So I know I’m really late to the JQuery party, but I’m here now, and I am liking it.

Overall, I’d recommend taking a look at JQuery if you are like me and hadn’t really used it until now.  It definitely is a valuable skill to develop and is growing at an extremely rapid pace.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

We can apply the principles I am about to describe in a variety of contexts.

• Determining how to best slice up a fatlog
• Adding tasks to a backlog
• Refactoring or writing methods
• Creating database tables
• Designing a UI
• Designing an API

Small = Simple

Software development, or rather software craftsmanship, is about managing complexity.  It always has been, it always will be.

Small things are typically more simple than large things.  Constraining size forces us to constrain complexity.  This is good.

We can built very large seeming complex things out of simple blocks.

Consider the reason why we break up our code into methods instead of writing it all in the main block.

A simple design is the difference between having a 10 year head start on the mobile phone industry and creating a phone that everyone hates and only ends up using as a basic phone, versus releasing a phone and in a very short time changing the world.

Small is easy to understand

This reason is essentially the same as simple, but is worth its own treatise, because it is so important.

Having a unit of work that is easy to understand greatly increases the chances that it will be:

• Done right
• Done at all
• Done quickly
• Communicated and passed on correctly and easily

Small things are easier to understand.  Almost any complex concept can be broken down to small enough pieces that it can be understood.

You will be amazed how much more work gets done when people understand the problem they are trying to solve.  Which brings me to the next topic.

Problem admiration

There is nothing… and I mean nothing, that will hamper productivity like problem admiration.  If someone thinks a problem is large and complex they will sit and admire that problem instead of working on it.  It is basic human nature.

Look at your own life.  Look at successful programs for life organization like Getting Things Done.

• Why aren’t you cleaning your garage?
• Why aren’t you finishing up that degree you wanted to get?
• Why aren’t you getting in shape?

Most likely it is due in some part to problem admiration.

I’ll give you a hint to cleaning your garage.  Break the work up into 10 – 15 small tasks.  Watch how much easier it will be to accomplish that goal.  Give it a shot.

It is hard to admire a small problem.  Take big problems and make them small problems whether you are designing a database, cleaning your garage or slicing up a backlog item.  Small is better.

Evolution

Iterative development is about evolving software.  We evolve software because of the feedback loop.  Short feedback loops are good, because they allow us to adjust.

Have you ever had a really bad remote desktop connection?  What happened to your mouse when you moved quickly in one direction?

Makes it hard to control doesn’t it?

The smaller the piece of software you build, the shorter the feedback loop is.  If you want to control the evolution of your software, make the feedback loop short.  If you want to make the feedback loop short, make the slices small.

Estimation

Want to know how long it will take me to write code to reverse a string?

• About 5 minutes.

How about how long it will take me to write this blog post?

• About 30 to 45 minutes.

How about how long it will take me to build a dog house?

• I don’t know.  About a day maybe.

How about how long it will take me to write a book?

• I have no idea, but if you make me guess I would say 5 months give or take 5 months.

Excuse the crappiness of my examples, but I hope you can see my point.  The smaller the item is, the easier it is to estimate the time it will take to complete.

If you have been working in software development for any length of time you have probably come to the realization that tasks estimated to take an hour usually take an hour, but tasks that are estimated to take one day rarely actually take one day and sometimes end up taking a whole week.

Think about a more practical example.  Can you show me with your hands how big 1 foot is?  Okay, now look outside and eyeball 500 feet.

Progress

There is no better motivator than making progress.

This benefit is purely emotional and artificial, but we are emotional artificially inspired beings.

Everyone loves making progress.  If you break things down small, you can chart your progress and see that you will indeed finish.

Imagine a progress bar with 2 big blocks.  Wouldn’t be very inspiring would it?

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

This book is a self-published book, which is really a collection of essays.  Be prepared for that before you read the book, so that you know what to expect.

It is not a book that tells you how to exactly do Kanban or Scrumban, but it gives you ideas about Kanban and lean concepts and how to solve certain problems you might face in implementing a Kanban process.

Some parts of the book might be a bit difficult to understand without a background in lean methodology, but overall most of the common problems and solutions are understandable.  This is definitely a book you could study and contemplate on as you read through the material and look at the charts.

Good:

• Excellent use of diagrams and pictures of real Kanban boards to illustrate points.
• Lots of different solutions for common Kanban problems.
• In depth talk about strategy and reason behind different possible solutions.
• Several unique perspectives on many of the concepts presented.

Bad:

• Not exactly an easy read.  It is a little rough and some of the concepts rely on knowledge outside of the context of the book.
• Some of the assumptions are a little broad and aren’t backup up by much real data.

What I learned:

This book really expanded my mind about different ways of implementing Kanban and solutions for some of the common problems.  Some of the solutions surprised me, but made sense.

I learned more about the reasoning behind limiting the WIP to force the system to self-correct.  I had not considered that strictly limiting the WIP would force freed up resources to automatically move to help resolve the clog in the pipe, since they will not be able to take in new work.

Corey presented a great technique on planning by having a just-in-time planning session when the number of items in development reaches a certain threshold.  I had heard of this technique before but had not seen a practical implementation of it.

I would definitely recommend this book to expand your thinking on Kanban software development.  If you are looking for instructions on exactly how to set up your Kanban process, this book probably won’t help you, but if you are looking to understand more about the why of Kanban and how to solve particular problem or pain points, get this book.

There is one coming soon, but I wanted to talk about why it has been so long.

Simple answer… I stopped reading.

What happened?  Well, I got caught up with switching jobs twice.  Lots of different things going on.  I started a running program, etc… etc… excuse… excuse.

I wasn’t following my own advice.

It is really important to take a moment every once in a while, when you feel like you are off track or not reaching your goals, to reassess your priorities and goals and figure out what you need to get back on track.

You have to set a schedule

That is primarily where I failed, and that is how I am succeeding now again.  At one point I was reading through books about 2 a month, but pretty soon a few months passed by without one book read.

When I was successful at reading, it was because I had set up a schedule or reading every day for so much time.

The simple matter of it is, as humans we are not good at making good choices about priorities without explicitly planning them out.

Now that I have set up a schedule of reading a minimum of 30 minutes each day, I am making progress again, and much faster than I thought.

Aren’t you being a little strict?

You may think that just reading blogs is enough to keep up with the information stream, and it may be, but it probably isn’t going to really expand your mind like a book will.

Why I recommend reading technical books (although, I would argue a book on people skills and other self-improvement books should also be mixed in.)

Breadth of knowledge will increase.

You will learn more about things and understand more of what is available to you even if you do not employ all the practices and technologies in the books you read.

Depth of knowledge.

Sometimes drilling down into an API or deep into a technique can help you truly master a technology or practice way more than hacking out code or consulting APIs to just find what you need to know.

Motivation.

This one is a surprise to most people, but what you read is what you are excited about, not the other way around.

Try it if you don’t believe me.  Pick any topic and start reading about it.  You will become passionate about that topic.

If you want to be a better software developer, read about software development.

Reputable source of authority when influencing decisions.

You can have the best idea in the world, but if your only authority is yourself, it doesn’t hold much credibility.  It is much more effective to say, “I think we should do it this way.  In Code Complete, Steve McConnell says…”

Unconscious knowledge absorption.

I have always been amazed by how much information I picked up from reading than what I was conscious of knowing.

Many of my blog posts will echo things I have read in Code Complete, or Clean Code, or any number of other books I have read, which I do not even consciously recall.

Sometimes when I write code, I intrinsically know it is the right way to do it, because of an unconscious conditioning.  (Make sure you read good books, or you will have the negative aspect of this effect.)

My little tip

One great way to get your reading done, and to stay in shape at the same time, is to do it on a treadmill.

I have been doing this for awhile now, and it really makes me feel like I am using my time wisely.

You can just walk on the treadmill, set a little incline to burn some extra calories, and after awhile you’ll forget you are walking.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

public void CreateFromLine(string line)
{
    var columns = line.split(',');

    this.Name = StripQuotes(columns[0]);
    this.Description = StripQuotes(columns[1]);
    this.Category = StripQuotes(columns[2]);
    this.Stuff = StripQuotes(columns[3]);
    this.MoreStuff = StripQuotes(columns[4]);
    if (columns.Count > 5)
        this.EvenMoreStuff = StripQuotes(columns[5]);
}

Or some code like it.  It is pretty common to parse a line and then take each column and store it in your object as data.

One of the annoying problems is that if you have optional columns you have to check to see if they are there before you can parse them.

You’re also repeating your code to strip the quotes off, or whatever other preprocessing you are doing, all over the place.

I know you can use a data driven approach to specify column to property mappings, but I wanted a really low tech, simple solution.

I finally came up with one using one of my favorite C# constructs.

Action<> is superb for solving these kinds of problems

See if this code makes you feel any better:

var propertySetters = new List<Action<string>>
{
    value => this.Name = value,
    value => this.Description = value,
    value => this.Category = value,
    value => this.Stuff = value,
    value => this.MoreStuff = value,
    value => this.EvenMoreStuff = value
};

var columns = line.split(',');

foreach (int columnNumber = 0; columnNumber < columns.Count; columnNumber++)
{
    var propertySetter = propertySetters[columnNumber];
    propertySetter(StripQuotes(columns[columnNumber]);
}

It may not seem like much.  It is not really a reduction in code, but we have done a few important things here.

• Removed the explicit handling of optional columns, since we are now only populating columns that exist.  (Adding a new optional column is as easy as adding one more line to the list.)
• Removed the responsibility from the code of explicitly tracking the column numbers.  Column number mapping now is implicit by the order of the columns in the list.
• Removed the hidden code duplication of having calls to StripQuotes repeated for each column.
• Separated the mapping of properties to columns from the assignment of them.

That last point deserves a little more explanation.  Why do we care if we have separated the mapping of properties to columns from the assignment?

The answer is not obvious until you try and use this same code to handle a different set of columns, or columns in a different order.

By separating out the mapping, we can pass the assignment code a different set of mappings, and it will still work.

This allows us to reuse the logic we have in the assignment of the columns to properties instead of rewriting it for other column to property mappings or orderings.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.