But we are “Agile”

I’ve heard that phrase many, many times.  Usually it’s used to justify not following the current processes, like mashing sizing and grooming together instead of having separate meetings, or making changes to a story after it’s partially (or fully) developed.

Developer:  The change you are asking for will require re-doing most of the development already done this sprint.  We’ll need a new story for this that we can work on in the next sprint

Product Owner (or any business lead):  But we’re agile, we should be able to make this change now.  You are already working in that part of the code…

It seems like being “Agile” is synonymous with not having to follow a defined process to some people.  In my opinion, this couldn’t be farther from the truth.  Agile works best when you strictly follow your process. Always, no exceptions, ever.  I think that’s worth repeating: Agile works best when you strictly follow your process. Always, no exceptions, ever.


Notice that it says your process. I’m not suggesting to follow some process in a book somewhere.  Follow the process Your Team created.  Assuming your team is following agile practices, the team has developed a very good process that works best for them, and is constantly reviewing and making improvements. If the business goes around the process, then the team is being robbed of the opportunity to improve it.

If having separate grooming and sizing meetings is too slow – isn’t it too slow for all of the other stories? If changes are needed after development is started, wouldn’t it be better to figure out why we have these late changes and how to avoid them?

It’s better to bring up the cases where the process is not working well and fix it for all stories/projects, not just the special ones.  If the process isn’t fixed, you’ll have to keep going around it every time you have tight timelines (or whatever the reason for breaking the process).

Agile works because it makes it very obvious when part of the process isn’t working well.  Everything is done in very short cycles – grooming, sizing, sprint planning, and retrospectives all happen every single sprint (if you are doing it “right”).  If it doesn’t work well, it doesn’t work well all the time.  People get tired of the process failing and will find a solution quickly.  If the pain is alleviated by not using the process, there is no motivation to fix it, so it stays broken.

My suggestion:

Follow YOUR process religiously.  If it doesn’t work well for something, fix the process, don’t avoid it.

Then, when this same type of issue happens again – your process will handle it. Sure, it might take a couple iterations to find a process that works, but you’ll be on the way to success.


Book Review: The Five Dysfunctions of a Team

I was recently given a copy of this book (The Five Dysfunctions of a Team by Patric Lencioni) by a co-worker. It is a pretty easy read. The majority of the book is a narrative/story about “Kathryn” taking over as CEO of a company with a very dysfunctional senior leadership team. She walks her new team through their dysfunctions and points out ways to deal with them.

The 5 dysfunctions talked about in the book are: Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability and Inattention to Results.
Reading through the examples displayed by the team described in the book, I could certainly see some of them in the teams I work with and have worked with in the past. “Kathryn” gives clear guidance on how to deal with these dysfunctions.

The last chapter or so steps out of the story and gives clear definitions, examples and suggestions for solutions to the various issues. It does not make the assumption that all teams are the same, but gives several different techniques to help overcome each of the dysfunctions, and points out that they are all inter-related. You rarely have only 1 of the dysfunctions, but instead have many or all but at different levels of dysfunction.

Given the relatively easy read and the quality of the information, I would recommend this to anyone who leads a team. It’s equally good if you are just part of a team and not leading it, so you can work toward avoiding the dysfunctions at least as 1 member of the team.

Agile Mindset

Bad Code – Snippets from production

True, false … or maybe?

Lets start with something on the funny side. Some of the code that I have come across in our system.

boolean isFutureDeal = Boolean.parseBoolean(request.getParameter("loadFuture"));
if(isFutureDeal != true){
       isFutureDeal = false;

If it’s not true, set it to false. I guess this is to make sure it isn’t set to that other boolean value – true, false, maybe.

Give me that.  What?!  I don’t need that.

public ShoppingCart createNewCart(ShoppingCart cart, HttpSession session,
                     MiniUserBean member) throws Exception {

              if (cart == null) {
                     session.setAttribute("shoppingCart", new ShoppingCart());
                     cart = (ShoppingCart) session.getAttribute("shoppingCart");
              cart = (ShoppingCart) session.getAttribute("shoppingCart");

The cart object is passed in, but the first thing we do is read it from the session, so why even pass it?

Day of the week calculation

[pseudo-code...actually seen in production]
if (date == "11/28/2016" || date == "12/5/2016" || date == "12/12/2016" 
     || date == "12/19/2016" ...) {
          dayOfWeek = "Monday";
} else if ( date=="11/29/2016"...

You get the idea.  There were about 1/2 year’s dates in the if statements.  I found out about this gem when a customer called and complained that their script was not setting the day of the week any longer.  This was in perl, and I replaced that huge block with a few lines that would forever compute the day of the week.

Unit Testing – Part 1

I’m fairly new to writing automated unit tests. I’ve read about it and I’ve tried it out and we even have a handful of java classes (10 to 20) that have full coverage from unit tests. But now it looks like we might be changing our view of testing and diving in head first.
So here are some things that I’ve learned that I didn’t really pick-up on when reading the books about JUnit.

Step 1 – Write Testable Code
Something that I missed when reading books about unit testing is that you have to change the way you write the code in the first place. This is generally a good thing, but something that is difficult to do across an entire development team.
Long methods – are very difficult to test – We have some methods that are over 1000 lines, it’s not easy (maybe not even possible) to test a method that is this big.

Dependency Injection – methods that create their own database connections, or create any new objects directly are very difficult to test well. For legacy code, I’ve found that a good way to handle this is updating the method to take these objects as parameters, and then creating a new method with the old signature that simply creates the objects and passes them in. This allows you to create mock objects for database connections, etc. which lets you test all the code in the method without needing a database to connect to.
public User buildUser() {
Connection conn = getConnection();
return buildUser(conn);
public User buildUser(Connection conn) {
... existing/old code to read user object from databse ...
return user;

References to Static Methods – Static methods are easy to test. Code that calls static methods are VERY hard to test, because you can’t mock/stub out the static methods. So you end up having to test all the code in the static method along with the code in the method you actually want to test. I don’t think small methods that take few or no parameters from well tested libraries are much of an issue. For example, if your code calls Math.random(), it’s still fairly easy to test. But if you have a lot of “utility” methods that take large objects as parameters or that do complicated logic it’s difficult to mock-up the test data to get those static methods to return all the different scenarios that allow you to run through all the code in the method under test.

If developers are writing code that is difficult to test, they will hate writing unit tests. It is time consuming, the tests will break often from small changes in the code, and code coverage will be low. They need to change the way they write the code in the first place before you can be successful in implementing unit tests.

In general, testable code is better quality code anyway. Having short methods that “Do one thing”, and creating methods that use Object Oriented Design (ie: not static) are easier to maintain, easier to read, and much nicer to work with. This is a side benefit of implementing unit tests.

I’ll continue with my lessons learned in later posts. Something I’m still not sure how we are going to handle is all the existing legacy code that doesn’t fall into the category of “testable” or at least not “easily testable”.

And so it begins…

This will be a place to post our musings of software development and working in the software development industry.  We are software developers and husband and wife.

About Blair –
I work at a loyalty and incentive company that provides programs similar to what credit card companies have (earn points by using your card, and redeem the points for a variety of rewards). I started with the company early in its’ life, before they actually had a product to sell, and helped build the application platform from the ground up. I have grown with the company over the last 10 years. In the early days we were really focused on getting the application working and adding new functionality – really without regard for code quality, capacity planning, maintenance time, etc. Now we are much more concerned with these things and spend quite a bit of time optimizing for increased capacity, making maintenance easier, etc.
I also helped move the development process from waterfall to an Agile (Scrum) methodology. I’m a strong believer in Agile processes and I’ve been working to improve our processes and empower the team members – which is not always as easy at it sounds (and it doesn’t sound easy).

About Becky-
I have been developing software professionally since 1998.  I have worked in a number of industries using both waterfall and agile methodologies.  When I started working, I simply wrote the code needed to get the job done.  I didn’t understand a lot about good architecture, clean coding, etc.  I sometimes considered myself a ninja coder, because I could sneak in and make the change without disturbing the rest of the code.Nearly a decade ago, I started learning more about agile methodologies, clean coding, design patterns, etc.  I was lucky enough to land a job with a couple of amazing developers who had been practicing these things for a while.  Working with them doing extreme programming really accelerated my learnings and my passion for this approach.
I consider myself a software craftsman now.  I am very passionate about creating quality code that is well tested and maintainable.  I also believe very strongly in the agile methodologies as a way to help ensure that the work that is done is done well.

What’s Covered in this Blog?
We don’t want to limit ourselves to one specific topic, so we’ll have posts about Agile/Scrum, Code Craftsmanship (code quality, clean code) – including examples of what NOT to do, and anything else that we think might be useful to others.

Java – Static Methods

I currently work in a code base where static “utility” methods are used fairly often.  This probably stems from the legacy of the code base.  Back when the company was just getting started, there were only a couple of developers (including myself).  While we all knew how to write Java code (syntax), none of us knew how to write good Java code (Object Oriented, encapsulated objects, etc.).  So we wrote a bunch of static utility methods trying to keep the code clean.

Ten years later, I’m still with the company (as are 2 of the other 3 original developers) and we are still working in the same code base.  The company has grown steadily and there has never been available resources to take on a whole system re-write.

The original code from 10 years ago isn’t the only problem.  The development team has grown significantly over the years as well.  Most of the team consists of developers that have very little experience in Object Oriented Java before joining our team.  So they tend to use the existing code as an example of how to write new code, which means more static utility methods and the cycle continues.

So what’s wrong with Static Methods?

If used in the right context, there is nothing wrong with them.  But using them to often or in the wrong places has several issues.

Automated Unit Testing

Static methods make implementing automated unit testing very difficult.  There is no easy way to stub out the methods.  There isn’t an interface to program to, and you can’t use polymorphism to override the static method to return a specific result for testing.  So when writing unit tests on code that uses static methods, you end up testing the not only the code in the method you are trying to test, but the code in the static method(s) as well.  This is often the biggest reason given for not using static methods.  The company I work for doesn’t use automated unit testing (I’ll post about that another day), so this doesn’t work as a reason not to use them for us.

Object Oriented

Static methods do not extend any other class or methods and cannot be extended.  So the code in them can not be reused – unless it does exactly what you need it to do already. Static methods are not Object Oriented in anyway. I’m not saying they can’t be utilized in OO code, just that they themselves are not.


Static Methods alone don’t make for hard to read code, If they are over used or the class or method name is long it can certainly detract from readability:

// Harder to read
User user = new User(StringUtility.removeSpecialCharacters(firstname), StringUtility.removeSpecialCharacters(lastname));

// Easier to read
User user = new User(firstname.removeSpecialCharacters(), lastname.removeSpecialCharacters());

Passing the same object to multiple static methods to have it just return the same object (with modified data/state) quickly becomes difficult and tedious to read.

// Harder to read
order = CartUtility.calculateTaxes(order, billingState);
order = CartUtility.calculateOrderTotal(order)
print("OrderTotal:" + order.getOrderTotal());

// Much easier to read
order.calculateTaxes(); //better yet, make this part of calculateOrderTotal()
print(“OrderTotal:” + order.calculateOrderTotal());

So when SHOULD I use a static method?
You should use a static method if (and only if) ALL the following are true:

You are writing utility class and they are not supposed to be changed.
The method is not using any instance variable.
You aren’t passing in a parameter and getting the same object returned. Generally this means the method should be put in the object you are passing/returning.
It just doesn’t make sense to create them as instance methods for some reason.
You are sure that the definition of the method will never be changed or overridden.

What are your thoughts? Leave a comment below and let us know