Ted Wise

My first job out of college I was given a development task by my manager.  I went through the requirements and noticed that it wouldn't be possible to implement them as written.  So I gathered up my materials and walked into my manager's office.  I explained to her what the issue was and told her I couldn't complete the assignment.

She looked at me for a moment, as if expecting something more, and then said, "So how do we resolve this?"  I was taken aback.  I told her again that the requirements couldn't be implemented - as if she hadn't heard me the first time.

She looked at me for another moment and said to me, "Don't ever come into my office again with a problem until you've spent time thinking of solutions".  Her message was crystal clear.  It wasn't her job to solve my technical problems.  That's what she was paying me for.

As architects and developers it's our job to solve those technical problems and implement realistic solutions.  It's not a viable option to reach a road-block and throw up our hands.  We can't rely on anyone else to bail us out when the going gets tough.

I've taken that to heart for the entirety of my career.  That meeting with my long-ago manager was the last time I was at a loss for alternative solutions.  And it's a lesson I've attempted to pass on to others.

I've noticed again and again that's its a common problem.  Especially among developers who think of themselves as cogs in the machine.  You're not a cog.  Your job is a difficult one but you have the capacity to solve your own problems and find your own solutions.

So the next time you realize that you've reached a difficult stage and that you cannot solve it on your own, don't setup a meeting or send out an email until you've worked out some alternatives on your own.  You may not have found the final solution but you'll make it clear that you didn't just give up.  Because that approach, is unacceptable.

Ok, I'm kidding about the lazy part.

But here's an interesting open source tool - Cucumber. It's a Behavior Driven Development (BDD) testing framework.

You write the test scripts in plain language:

Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses
Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 3 courses A,B,C that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| title |
| A |
| B |
| C |

And then interpret them using test code:

Given /there are (.*) courses which do not have the topic "(.*)"/ do |num_courses, topic_name|
 ... write the code to get the number of courses without the topic and verify the number...
end
 
Given /there are (.*) courses (.*) that each have "(.*)" as one of the topics/ do |num_courses, course_names, topic_name|
 ... write the code to check this one too...
end
 
When /I search for "(.*)"/ do |topic_name|
 ... search for the topic name and save the list of courses ...
end
 
Then /I should see the following courses/ do |table|
 ... check that the saved list of courses matches the data in the table...
end

The idea is to let the tests describe the behavior of the system and then code to fulfill the tests. Cucumber is written in Ruby and so are the tests. But it runs on JRuby and on IronRuby so it can be used to test Java code and .Net code.

I develop by some general principles. One of the strongest is "generous on input, strict on output". This means that the code should be tolerant of variations in it's input but should be strictly correct when outputting data. This ranges from the small to the large.

As an example, when you accept a boolean as a string, ignore the case and allow it to be expressed as "1, 0, T, F, Y, N, TRUE, FALSE, YES, NO, etc.". If it's not anything you're prepared to see, assume it's false. But when outputting a boolean as a string, stick to one single convention and one single case religiously.

When you parse a custom format file, assume fields might be left out, or that they may be malformed. Attempt to "do the right thing" with the values you do get and set sane defaults.

Do you do this in every single routine throughout your code? No, you do it at the boundaries. But those boundaries can be hard to see. If you're writing a Java library, you do it at the published interface points. If you're writing PL/SQL packages, you do it on the non-local procedures and functions. If you're writing anything that reads from the network or a file, that's a boundary point. Anywhere your code will reasonably connect to code you didn't write and data you didn't create, is a boundary.

There's another name for this: code defensively.

Assume the other programmers are wild anarchists who revel in destroying your code. Assume they don't read your documentation and will call your routines simply by guessing what the parameters mean. Because that's exactly what will happen.

This approach will save you a ridiculous amount of time dealing with defects both subtle and obvious.

But there's a flip side to this. It's called failing fast. You should attempt to be lenient with what your code accepts, but when basic requirements are validated, you should fail fast and clearly. Is that parameter absolutely required and can never be null? Test it right at the start and throw an exception that explains exactly what was wrong with the input. Don't let the null percolate through the code until it causes a problem.

With these two techniques you'll find that consumers of your code will have an easier time. You'll find fewer defects raised. And you'll find that your own maintenance of your code will be easier.

We accomplish tasks. We get things done. We meet schedules and check off boxes on requirements lists. We implement features and run tests.

It doesn't have to look pretty. It doesn't have to be polished to a high sheen. It has to be professional and correct.

This is how you mark off requirements and move forward. This is how you check the box next to features. This is how you get things done.

But what would it be like if you could make it as perfect as you could? What would it be like if you tried to polish it? How would it feel if the client said making it right was better then just making it?

Let's use cell phones as an example.

Any idiot can do cut and paste. It's in Windows. It's in Linux. It's in OS/X. It's on smart phones from every vendor. It's basic.

And it's not (yet) on the iPhone.

How can they be so bad at their jobs that they can't implement such a trivial feature? Because they tried to get it right. Not done. Done right.

Stack an iPhone against an Android. The iPhone loses on features. It will probably always lose on features.

Where's email search? The Blackberry has it. What a rip. Look at Apple using hype to sell a sub-standard product. Search is basic. Put a box at the top of the mail program and index the mail. How hard is that?

Whenever something doesn't make sense it helps to step back and ask the question - why? Why isn't something as basic as cut and paste already done? Why isn't mail search, something so simple, already done?

Because the implementers don't feel the standard paradigms are good enough. They don't want to just get it done. They want to get it done right.

This isn't an approach that Apple has invented. You can see it in many places. You can see it in Microsoft's UI refresh of Office. You can see it in the Web 2.0 sites that focus on usability over feature set. You can quibble with the chosen solutions. Maybe they're not your cup of tea. Maybe you don't even see the benefit of spending the time and effort to find a better solution.

I've been down both paths. And I can tell you which one I prefer. Elegance over junk. Simplicity over complexity. Thoughtfulness over thoughtlessness.

Hopefully it's not just me.