The notion of a framework that works with your existing objects is great. And, if it actually does work with your existing objects, that’s even better.

But, when everything in my system–through ignorance and/or framework–has become a DTO, it kind of pisses me off.

I mean, why is there a setter there? Can the object change state during it’s lifetime? If so, why is there a setter? Why not some other name that doesn’t have to do with implementation? If not, why the hell is it there? Why is that getter there? Do we need to return that value? If so, why? Is somebody asking the object for something rather than telling it what to do? If not, why the hell is it there?

What I’ve heard a lot of is: “Just new up a POJO, and the FlarbleMeister framework will do the rest. It is freaking awesome.” Because of ignorance, framework, and ignorance of the framework, I have to deal with code from the database to the UI with nary a real object. You know, the stuff that can make code easy to work with, the stuff that helps explain the system and allow others (developers working on the code years from now) to intuit what is supposed to happen.

So, please think about it: Is this a real object or a glorified DTO? If it is a DTO, does it belong at this layer in the system? Does it make sense to have it at all? And, please, stop calling it a POJO.

I could see why one wouldn’t want to have tests for said classes. They suck to write, and are supposedly so simple you have high confidence that they work correctly. Still, it bugged me. Then, a teammate pointed out something. In these cases, the value of the unit test isn’t necessarily the design aspect. It is for future users. The test is a set of expectations for the data structure class, a set of expectations that all other classes it interacts with will have.

If you don’t have a test, when you make a change, you aren’t going to have confidence that everything is working as it should. With a test, you will know what the expectations are if you need to make a change. And, if you make a change to the data structure class without regard for the test, the existing test should give you some feedback, and a little more confidence.

In this case, I think the value is for future changes. It isn’t nearly as cool as having a test drive your design (which it still can), but it is just as important.

As to why we have all these, data structure classes and what I think of it, that’s another post…

Expanding on this, I’ve noticed that when I am just starting development, there are no mocks or stubs. As I progress, there are instances where I am using some stubs in tests. And when I almost have functionality, I am using mocks when testing. I use stubs at a “lower” level and mocks at a “higher” level.

I think that this makes sense. Once I’ve got my base set of objects, I just want to make certain that they talk to each other in the appropriate manner. I trust that the individual objects know what to do. At that higher level, it’s the interaction I want to test.

• Bigger files — typically bad
• Bigger blocks of text — typically bad
• Lots of blocks of text — typically bad
• Lots of indentation — typically bad
• Inconsistent indentation — typically bad

Now, I don’t think that if any of the above are present, it is a metaphysical certainty that code is bad. And, just because some code does not have any of the above, I don’t think it means it must be good.

I do think they are good predictors. In my experience, the vast majority of the time if I see something that has all of the issues listed above, it is going to be difficult to work with. Conversely, if it is going to be easy to work with, it will typically have none of the aforementioned issues.

I figured I’d have enough information to know what was going on and to verify my changes didn’t break anything. The tests did provide some documentation, but it was really about the mechanics of what we were doing. I knew that I could make changes, but still felt a little uncomfortable. For me to be really comfortable making the change, I needed some context—the “why”.

I know others had a few of these uncomfortable moments with the code. A number of times we might have wanted to make a high level change, but because we didn’t know the “why”, we didn’t have the necessary confidence to do it.

This got me thinking about some aspects of the BDD-type stuff that I like. One of them is the whole “As a..”, “I want to..”, “So I that…” preamble for story frameworks (see RSpec or JBehave for examples). With some documentation about the roles, the actions, and the outcomes, you have that necessary context when you come back to the code several years later.

This context is absolutely needed at the acceptance test (story) level. At that level, it ceases to be about the units, and is about the whole. When we start making changes at that level, we need to know the “why”. Otherwise, our software just ain’t gonna be soft.

Customers make decisions based on feedback from sources such as the current application, the tests for the parts of the application that are currently under development, their future needs, and what the development team says they can do in an iteration. The end result should be customer-approved software.

The implementation of the system outlined above may vary, but they key features remain. And, I think too often there is an implication that there is a distinct wall between producer (development team) and consumer (customer). The development team makes the stuff and the customer must approve it.

Contrast this with another approach to creating customer-approved software: have the customer write the software. Supposing the customers are savvy enough and/or have the right tools, if they write the software, it would be customer approved, too.

I actually worked at a place where this was the case. The first release of the product was written in a scripting language by industrial engineers that knew the domain. And, you know what? It worked. It did what they needed it to do at the time.

Notice I said “at the time”. As time went on, keeping the software “soft” proved to be difficult. Maintainability, extensibility, and testability went out the door. I don’t blame the people that wrote it. That kind of stuff is really part of the software development trade. In fact, I believe that if some sharp developers had been involved earlier, there would have been few issues.

What if the customer is not savvy enough? Provided we are always striving to improve our software and development process, I think eventually they will be. The longer we work with a customer, the more likely we will be creating tools for the customer to write some of the software themselves.

I am seeing hints of this at my current employer. On one of our projects we’ve reached the point where we have DSL for describing and testing our system that is used by developers, testers, and business analysts. We have super-tight iterations, with very few defects. If we are going to take a next step, it seems that step would be to use the DSL to create production code. It’s the next logical step.

I’ve noticed that this code—production code and tests—is very chatty. I mean, I can’t run a test without War and Peace being written to the console. My guess is that this due poor tests.

When the code is unfamiliar, we have a few options to get our heads around it. The first and best option (in my opinion) is to run the code’s extensive and well-maintained test suites. The tests will serve as documentation for the code in its current state.

What if we don’t have those tests? I guess we start reading through the code, using the debugger, and output statements to the console. See where I am going with this?

Writing output/debug statements is fine for short-lived (think minutes) testing/code archeology. Once you answer your particular question, get rid of it. If you need that output to test something, put it in a test. If the output is something you’d like to have when the production code is running, log it. Either way, those output statements should not get committed.

Why? Software is complex. We try to reduce the complexity. Tests and production code that spew line after line to the console when it is not needed add complexity. Consider a test that prints a stack trace from an exception to the console, yet passes. How are you going to feel about the test? The production code?

In many places that claim to be agile, rather than collaboration amongst stake holders, there’s conflict. The process is more valuable than working, deliverable software.

“We can’t release your well-tested, customer-requested, money-saving feature now.”
“Why?”
“Because we only release 3.2 times a year, per our process. This release would violate the process.”
“Process? 3.2?”
“Yes. The process keeps us agile and the .2 helps gives us some buffer.”
“I don’t even know what that means!”

When does this silliness end? My guess is about one developer-to-leader generation. The developers that experienced an agile working environment will want to take it with them as they start leading others. But, that’s only when you’d start seeing some changes.

No-Location
Separate the team. Make certain the customers, developers, testers, and other stakeholders are not anywhere near each other. As face-to-face communication is the most effective method of communicating complex issues, it must be eliminated.

Lengthen The Feedback Loop
By making certain that decisions cannot be made “just in time”, you can prevent real agility. Purposeless delays in deploying to production, ridiculously long testing cycles, and a barely working deployment infrastructure can be a real help here.

Time-Consuming Metrics
A superb way to waste time and kill morale is to forcing agile teams to prove they are agile by collecting metrics that do not really mean anything to the end customer. Extra morale-killing can be achieved by having people track every single task they work on to the hour.

External Organization
Don’t let the team self-organize. Hold back key pieces of information that could allow a team to self-organize, such as organizational changes or time line changes. Be sure to conduct daily meetings that really are just people “reporting up”.

Emasculation
If at all possible, make certain whoever has the ultimate say in what will happen (e.g., the project manager) is completely out of the loop with the day-to-day work. But, don’t let the team have any say in how things are going to get done. Prevent individual and team decision making.

These are just a few simple suggestions. Be creative. You can break their will if you put enough effort into it!

Since I develop test-first, I immediately went to the unit tests for this code and started looking around. I planned on modifying the existing tests, adding new tests, and refactoring along the way. This way, I would ensure the new functionality was working properly, and did not have any negative effects on the existing code.

I soon discovered that a number of the classes did not have any tests. Annoyed and disappointed, I set out to get some tests around the areas I was going to be touching. I decided I would go back and add more tests for other parts of the code if I had time.

As I worked, I was amazed at how difficult it was to get tests around the code. Strange dependencies, improper abstractions, and duplicated code hampered my attempts to test. Eventually, I made the tests I needed and left the code a little better than when I got there.

This experience reminded me of an old adage:

Listen to your tests.

Your tests can tell you a lot about your code, and not just in the “this method returns the input multiplied by 2″ kind of way. By examining what you must do to create a test you can learn much about the code’s dependencies, abstractions, and interactions.

Do you have to make all sorts of funky objects to test something? Is it impossible to test something “straight on”? Do the assertions you make in one class’s tests look pretty much like the assertions in another class’s tests? Do your tests take a long time to run? If you answer yes to these questions, your code is probably hard to test.

All of which leads me to another old adage:

If your code is hard to test, it probably sucks.