Being pragmatic is good business

Let's face it, being pragmatic is always good business. The only time being idealistic is good business is when the market demands idealism. And then that is simply the pragmatic choice.

Dynamic typing and the IDE

In further researching dynamic vs. static typing, the obvious question is how can the IDE make you productive, suggest method names, if there is no such thing as an invalid method name at compile time? How can it show you the documentation behind the code, if it has no idea what that method name will actually resolve to?

One way is to analyze all the code that calls the method. Some new languages are doing that to guess the type without you having to spell it out.

But it can't help you create a missing method in the correct class, because it wouldn't know where it is supposed to go.

Dynamic typing is great for scripting, where a script is defined as something that is not large enough to be a problem to erase and recreate when it gets out of hand. In such a context, static typing is overkill.

In a larger project, with many different developers and more limited channels of communication, I'm still looking for how to overcome the problems. So far it seems that people just shrug off the problem as small in practice. I suspect that their practice involves more serious and disciplined programmers than a lot of us have the luxury of working with.

UPDATE: I guess integrating something like this would allow the IDE to understand what is going on. Of course that doesn't exist yet.

I can say from experience that having a method that cannot be safely renamed will cause larger projects to not have their methods renamed, causing the code to age. You might hope that a bad "search and replace" refactoring would get caught by unit tests, but if the search and replace was thorough, then it wouldn't. It would just be impossible to rename the method in a specific context.

Much to learn

So I'm investigating Ruby on Rails (vs my more extensive background in Java) and I see this quote:

A solid suite of unit tests is every bit as good, if not better than, static-type checking. Because all you want in type checking is confidence that you haven't made the basic mistakes. A good set of unit tests will provide that for you.

I'm wondering what I am missing? The most common mistake in the lack of type checking is outside the unit. One class makes the mistake of calling this other class and they don't understand the type of the variable. Most commonly, it changes after it was first written. In fact, that is why those with a preference for dynamic typing like so much - you can change it so easily and just add a method.

So here I have a series of Unit Tests that check for one thing on one object, and a series of unit tests that make sure that when an external object is called, it will be called with the right parameters. Then I go and change that other class and all of its unit tests. How do I validate that all calling code kept up? A text search? But method names can be duplicated all the time.

I just don't get how static typing of an interface is not the only way to ensure that changes are propogated throughout the project. Of course many times you don't have that luxury (like when you are calling web services). But it seems like a good thing to have, unit tests or not.

The perils of customer service

Authorize.net took a dive in this web designer's view.

It just goes to show how a company can ruin 9 years of good service in two weeks. Two lessons:

1) The fact that someone wants to stop a current relationship doesn't mean they stop being an important customer. Treat them as such.

2) Your customers expect perfection. Aim to deliver.

Fortunately these days most companies don't differentiate themselves in customer service, so you don't have to work to hard to match them.

Of course you can never please everyone, and having an unhealthy need to please can be very distracting and unproductive. But here a great reference (and you have to think there are many more than one) was lost because of a drop in customer service. It matters, but companies don't know how to sell it, so they often skimp on it.

My worst experience was with a company that sold, for money, it support services (called Maintenance). When you called support you got someone with an Indian accent who didn't know, and who's manager didn't know, the meaning of the work "migrate." And this was a service they sold over and above the price of the product. The even solicited the business after we had let the maintenance laps. They won't get my recommendation again, even if their product is technically superior to the competition.

Conflicting Information

Courtesy of Slashdot we have this:

The study used energy company records from Indiana before and after that state mandated DST for all of its counties, and calculated that the switch cost Indiana citizens $8.6M per year. 'I've never had a paper with such a clear and unambiguous finding as this,' the professor said.

The recent changes to DST cost business an untold amount of grief, with old unsupported operating systems needing to be upgraded or patched by third parties just to deal with it, and even new software not functioning correctly until the patches are downloaded. So what lesson does a business learn from this?

One lesson is certainly that clear analysis is more important than acting on conventional wisdom. But more importantly, sometimes there are no clear answers. This is where leadership in business is so important. The leadership to decide when the evidence isn't all in and isn't attainable, and the leadership to stand behind that decision and make it work – but more importantly the leadership to know when something isn't working, and changing course where needed.

Government is not a business, and can't be expected to learn these lessons. But a business can, and should. Have you ever been on a project that was started under a premise that turned out to be false, and when that became known, it was more important to finish the project than to stop throwing good money after bad and admit that things were not as they seemed?

In a culture of blame, making such a decision is impossible. In a culture of accountability, where leaders are responsible to make the right decisions for the business based on the best facts they can get, a business can do so much better.

Undefined purpose

In Bob Lewis' book, he speaks about the importance of a project having a purpose. Often, in fact, a project has a purpose, but the purpose is vague. Especially in technology, people know that technology can lead them to great places, but they skip the part of thinking about how to get there. So it can look like a project has a great purpose, but place holders can become goals.

For example, a company may want to have very flexible software to be able to flexibly control business logic without development, increasing revenue by allowing the business to adapt quickly, and reducing on-going development costs. It will then decide that having a good workflow will help with this (the place holder).

Half way into the project, the workflow becomes the purpose, but the software ends up being very development intensive when it comes to the interaction with the user. The workflow, however, functions great. The goal was too hard, so a proxy was put in its place.

And the project was a great success, but not at doing anything anybody wanted.

IT Flexibility

Bob Lewis asks how if it is practical for IT to provide Virtual Machines as sandboxes for users to experiment with.

On the core question, it may have to do with your user base. If you run a business with technically inclined staff, it would probably work very well. If, on the other hand, you are in a more typical company where one or two people per department are savy enough to set up that access database, the people who might leverage that access database would probably be challenged by dealing with a whole seperate operating system on top of their current machine.

You also have some serious security considerations - and what do you do if that access database needs to touch some data too sensitive to expose to the sandbox?

The bottom line is there is no good substitute for good IT leadership, where part of IT's mandate is to provide tools for users to inovate and improve the operations of the company through technology.