Two bugs don’t make a right

Three lefts roadsign
While working on my new startup, we are doing a little bit of reasoning using implications. One of the more curious forms of implications is the negative form: consider the following exaggerated example:

  • a place being kid-friendly implies that it is not romantic.
  • a place being a strip club implies it is not kid-friendly

If we allow negative implications to be transitive, then it would follow that since being a strip club makes a place less kid-friendly, it makes it more romantic. We don’t want that. So I had to write some code to specifically ignore that situation. Before writing that, in the best tradition of TDD I wrote a test for two chained negative implications. I implemented the code, the test passed and I was happy.

For a while.

Fast forward a couple of weeks, and I’m trying out adding some negative implications, and the program doesn’t behave as expected. My code doesn’t work. I turn back to my test, check it out, and sure enough, all the thing the test asserts as True are actually True, and the test does test the right thing.

Digging deeper, I discovered the issue. I had two bugs: the first was that the code handling chained negative implications wasn’t working right. The second was in my graph building algorithm – it seems that I was forgetting to add some edges. What made that second bug insidious was that it hid the effect of the first bug from the test – effectively making the test pass.

So – for me it was – two negative implications don’t mean a positive one, and two bugs don’t make a feature.


My Startup –

Plnnr logoI’ve been waiting for this blog post for more than a year now.
This is my startup, If you want, go there first, form an opinion, and then get back here, I’ll wait :)
As you can tell, is an automatic trip planner – it saves you a lot of the trouble and hard work of planning a trip, and leaves you to decide just on the interesting things – what you plan to do on your trip.

I’ve been working on this with my partner, a product manager, for about 15 months now. We opened up the website for public access on July 18. Since then we showed it to people to get feedback but we didn’t publicize it.
Now, we’re starting to publicize it “for real”, with the goal of getting people to really use it.

We’ve been working on this project with no funding all this time, as our part time job, and as a result – there’s still a lot of work to be done. We have a lot of amazing features planned, and we have a great vision ahead of us, and we hope that we can achieve it.

This is the point where you come in – tell us what you think – here, or on our blog, and soon on the feedback system. We need your help!
Of course, if you find it in your heart to tell your friends who are planning a trip about our website, please do :)

There’s a lot more to be said about this project, and I intend to say it in future blog posts, so stay tuned!

CSS Javascript startup web-design

Website development and not supporting Internet Explorer 6

My partner and I started to work on a website a few months ago. We have a working prototype, and we are always improving it. My work is mostly concentrated on a smart Python backend, and on a Javascript front-end, while a thin controller acts as a messenger between the two.
Lately, I’ve worked on improving the UI. As expected, I rely heavily on CSS. I generate a lot of html elements using Mochikit and format them with CSS classes. While obviously better than the old alternatives, I still don’t like CSS. Maybe it’s because I don’t understand it deeply enough, but for me, there is still a lot of voodoo involved. An example I found, which luckily I didn’t run into yet, is collapsing margins.

Still, even with all its voodoo, CSS is bearable. At least until you get to IE. My latest run in with it was a scrolling bug, and I ran into many other issues. However, as much as I complain, I’m probably getting it easy, as when we started work, we decided not to support IE 6, at least until required.
Our reasoning was:

  • Developing for IE6 both independently and consistently with other browsers has a high cost attached to it.
  • IE6’s use rates are declining, and will decline even more by the time we launch (See these statistics for example).
  • Our first versions were mostly required as a prototype to prove our technology to potential investors.
  • As a two-men team, and a one man programming team, we are very low on development resources.

Given my latest bout of UI programming, this choice made me just a little bit happier.