This was odd, but not entirely surprising. Bell Canada obviously has legacy software, and as a practitioner I can see how these bugs can get in. But did other people experience this? Did anyone else even care?

On my bill, I found that sometimes the taxes were being rounded up instead of down and other times, just completely wrong as it was off by at most 6 cents sometimes.

When you think about it, 6 cents is not a lot, nor is it worth 20 minutes on the phone with a Bell CSR who doesn’t stop laughing at you and making smarmy comments about writing you a cheque for $0.06.

But 2 cents, 6 cents, whatever, every month adds up. It adds up to $1.51 over a year in fact. And with 7-8 million customers who don’t notice, that’s a lot of revenue for Ma Bell.

So, I went immediately to Google to complain and sure enough there were other people experiencing the same problem but didn’t feel the need to fight it.

After talking to the CSR, it was revealed that this was in fact, by design. This is part of the billing software because they charge tax on every line item on your phone bill. If the line item was $0.35, they’d round up $0.0455 cents to an even $0.05.

On my last phone bill, there was over 200 line items, each one being either rounded up or down after having taxes applied. The end result? The sum total was off by $0.04 cents.

So how would you convince Bell to stop this madness? In high school, they taught us about significant digits and how you should keep track of significant digits until at the end before rounding the value. Clearly, whoever programmed this billing system is accumulating fractions of pennies in an off-shore bank account somewhere.

If you’re a small business or incorporated, you can claim back the GST that you paid. This means there is an opportunity here to actually make money! The key is to maximize the number of times Bell rounds down on each line item. That means making quick phone calls that last less than a minute repeatedly. If you do this a few thousand times, you might be able to make $0.50! Just imagine the money piling in!

I’ve made a quick chart of how this works out. Hopefully it explains things a lot clearer than I can explain.

Now all you need is a (money) Laundromat.

Google has quickly become a depot of innovation and an incubator of ideas. The challenge for the rest of us is to be able to co-exist and if possible, even succeed without being destroyed by Google.

Being an entrepreneur is difficult enough without having this looming cloud of Google sitting on top of you. Once you do find your idea and fall in love with it enough to accept that even if Google is doing it already, that you will still ford ahead and do it, then the fun starts. For the most part, the technology part is the easy part, its everything else that’s a pain. Marketing and sales can be tough and shouldn’t be taken for granted. Of course there are some who say that a product markets itself, and that usually just takes patience and hard work.

Check out the video, the intro is a little creepy and cultish, but the demo is pretty neat. You can skip ahead to about 8:02 of the video.

“On the other hand I don’t believe architecture is formed out of whole cloth. I believe that you assemble it one bit at a time, by using good design skills, by using good architectural skills, over the weeks and months of many iterations. And I think that some of the architectural elements that you create, you will destroy; you will experiment in a few iterations with different forms of architecture. Within 2 or 3 iterations you will have settled into the architecture you think is right and then be entering into a phase of tuning. So my view of that is that the architecture evolves, it is informed by code that executes, and it is informed by the tests that you write.”  – http://www.infoq.com/interviews/coplien-martin-tdd  

Frameworks that can assist in unit testing have been a major time saver for the amount of work that would otherwise need to be put in. I’ve recently re-discovered the joys of development, and in particular test-first development. Using the Spring TestContext Framework it has become even easier to not just do unit testing quickly, but also integration testing.

The importance of both is often understated, as integration testing is more crucial when there are external dependencies. With a few annotations, one can create an integration test simply by specifying the database connection settings and focusing on the critical test paths through the business logic.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"test-context-data.xml"})
@Transactional
public final class BidnessLogicManagerTest {
    @Autowired
    private BidnessLogicManager bidnessLogicManager;
 
    @Test
    public void shouldRetrieveIdentity() throws Exception {
        Identity identity =
              this.bidnessLogicManager.findIdentity(10L);
        Assert.assertNotNull(title);
    }
}

The test-context-data.xml contains your usual datasource, transaction manager and other bean configurations.

With this class, you can test logic with rollbacks, test without rollbacks, or you can set up transactions before entering them. If so desired, you can also extend AbstractTransactionalJUnit4SpringContextTests to have access to convenient underlying low-level classes.

This is the way to develop, and its unfortunate that developers will most likely miss out on this, as they are rushing to meet deadlines and pressured to push out code. Using annotations with the Spring TestContext Framework gets us one step closer to having a real internal DSL that allows us to develop in the context of the domain. We can start shedding all the baby fat of traditional Java development, and worry less about all the plumbing.

If Java is to compete with the young, fresh new blood on the horizon, it needs to continue moving in this direction. Java is a powerful language, but it must become more lightweight and faster to develop to stand up against languages like Ruby or even Python.

Looking at both of these language, I can immediately see the similarities. Neither requires compiled binary class files, and both are compact languages. Clearly, Ruby is the more trendy language as everyone and their roommate’s girlfriend’s dog seems to be doing it. So I chose Python.

Python is a fairly young language, currently in its 2.x incarnation, and 3.0 under development. Invented in late-80’s by Guido van Rossum, it is heavily influenced by Modula-3 and Haskell (!). It had gained a large cult following of hardcore developers and early praise from the likes of Martin Fowler. Fowler once wrote in his Patterns of Enterprise Applications book that he’d love to see Python give Java a run for its money. All we need is a huge corporation to back it, and a guerrilla marketing gambit.

In my brief excursion so far, a few programming principles have come into question. Revelations of the clumsiness of the Java language have surfaced and I’ve gladly enjoyed the experience so far. Certain things that only nerdy computer scientists would fine remotely intriguing, such as comparisons between statically-typed vs. dynamically-typed lanugages, checked vs. unchecked exception and verbosity vs. compactness of a language.

As architects and designers we are resolute in attacking problems creatively and without prejudice. As implementors and builders, we must understand all the tools available to us and appreciate the differences between each. Knowing the advantages and likely uses of one over the other will afford us a greater breadth of knowledge and allow us to make better choices.

So far its been very interesting. The most interesting is this article about Waterfall: Managing the Development of Large Systems The comments made by the readers are excellent, on both sides of the argument. I especially found this comment very insightful:

When you read the Agile Manifesto, note that it’s not about practices, or languages, or technologies. It’s about a management style, a style of leading an organization that is very different from the typical command and control, which is still frequently used, particularly in government contracting.

The Lean Software Development books do a great job of explaining this. I think it really boils down to how contracts are defined. Things like TDD and continuous integration are just lower-level details.

My experience with agile processes has been interesting, and I have started to wonder how we can possibly measure success when there are no metrics to go by. Are we doing the right thing? I’ve learned a great deal in the past few years, but mostly in terms of leadership and development practices. I’ve learned how to become a better coder, but more as an after-effect of following the Agile methodologies. I’ve become an advocate of Lean Software Development, but this can only be as matter of common sense. How do we recognize the need to be lean or to continue with “whatever works”? Perhaps in a few more years, these will become clearer to me (though I wouldn’t bank on it).