Tag Archives: software

Wise words about software

From a former Firefox developer, truer words were never spoken:

Software companies would do well to learn this lesson: anything with the phrase “users love our product” in it isn’t a strategy, it’s wishful thinking. Your users do not “love” your software. Your users are temporarily tolerating your software because it’s the least horrible option they have — for now — to meet some need. Developers have an emotional connection to the project; users don’t.

All software sucks. Users would be a lot happier if they had to use a lot less of it. They may be putting up with yours for now, but assume they will ditch you the moment something 1% better comes along — or the moment you make your product 1% worse.

I gave up Firefox as my main browser when Chrome decided to support WebGL on Linux, and Firefox kept back burnering it. Mozilla is now deprecating Thunderbird, which is the only product of theirs that I still use regularly. Guess that means I’m going to have to get used to GMail’s web interface eventually.

Sad to see something as critical as Mozilla, the beast that cracked the IE hegemony, become an also ran.

Why I became a programmer

Yesterday was not a good day. The reasons (plural) aren’t really important for the sake of this discussion. But at 7pm, with the day behind me, and an hour and a half before my wife   was scheduled to get home from yoga, I switched over to my emacs window, and started going after a problem I’ve been poking at for 2 weeks.

The problem, which had nothing to do with my day job, was how to seemlessly add some javascript to date forms in Drupal to make them more magically. The date forms in Drupal are honestly quite dumb. You get presented with From and To, Date and Time. They are initialized to “now”. But they are 4 fields, unlinked by code. This was the easy way for the developer to write it, but absolutely frustrating for the user. Especially if you’ve used systems where the To dates move forward in time to match changes in the From dates. Set From to Jan 24th, and the To date shouldn’t still be Jan 11th. Making it also move to Jan 24th might not always be right, but it’s almost always more right than leaving it unchanged.

I had figured out how to do this with jquery, with these fields, and have a solution for one of my sites. But this is something that would make a great Drupal module. One that requires no configuration, and just makes your user’s experience better. How to get there, required banging my head a lot on internals, reading a lot of code that I thought might be examples, and not getting anywhere. Last night, frustrated with things that weren’t this problem, I went after it again, this time by brute force. After about 45 minutes of trial and error, I found a hook I could use to patch myself into the execution stream at the right point. Better yet, it seemed like this was probably the right way to do it, not some dodgey hack. By the time Susan got home, I had the shell of this module mostly working. Not releasable yet, but the minimum viable piece was now done, and the rest was about cleaning up for release.

I felt better.

There is a longer story here about how I entered College to be a PhD Physicist, and I exited to do web development for the Sydney Olympics. But the key take away was a realization, late in my Junior year, that when I wanted to relax, I went off and coded something. While I could never point to the day it started happening, I do vaguely remember realizing that my happy place, my retreat from the stress of the world, was deep inside an emacs session for hours at a time.

The fact that the thing that relaxes me, writing software, also happens to be a key piece of a quite profitable profession[1], made me a fortunate individual. Having gone to college and watched the modern internet emerge, which is an even longer story, made me doubly so.

The best piece of advice I ever got was from my friend and mentor, Eric, in college. “The key to happiness is to figure out what you’d do anyway; then find a way to get paid to do it.” Even if this wasn’t my job, I’d be writing software. It’s what relaxes me.

What relaxes you? What would you do if money was no object? Why did you become whatever you call your profession? Drop a comment below, because I’m actually quite interested.

[1] Yes, I’ve been long enough in the Software Engineering space to know programming is a small part of it (especially at a large company), but it’s still a very important part.


Maybe it shouldn’t be Computer Science

I had an interesting conversation at lunch yesterday when I met a CS professor at a local college. He’s got nearly 15 years industry experience, in addition to a decade being in academia, so exposure on both sides of the fence. During the course of the conversation I asked him what triggered the transition. His response was that he didn’t really enjoy programming.

There’s nothing wrong with that answer. I’m always jarred by it when I hear it from folks, because programming is what I love. But everyone’s different, an there is a lot more to computer science than just programming.

Over the course of the day that statement kept coming back to me, and I realized I’d heard it a lot of times in the past. The vast majority of CS profs I had during my graduate degree were in the same camp. Friends that are in CS academia, tend to lean the same way.

Art and music programs in liberal arts schools are a combination of practitioners and theorists, attempting to build a well rounded art student on both fronts. So why is CS still mostly theory in these environments?

The theory parts of CS wouldn’t have been my thing as an undergraduate either. Much like calculus being pretty boring in high school, but becoming down right compelling in my college physics classes when it was a tool to solve a problem, and not just theory that stood on it’s own. Without a body of work that’s tangible, the theory is much less relevant.

So maybe it’s time to call it something other than Computer Science. Software Engineering has the no no of the word Engineering, which doesn’t go over well at liberal arts schools. Apparently, Informatics is the monkier in much of Europe, and given the rise of data analysis, that’s probably as good an idea as anything else.

Upcoming Talk: Getting Involved in Open Source

We’re circling around on January again, which means it’s time for my annual talk at MHVLUG. One thing that’s really fascinated me over the last year is recovering and revitalizing open source projects whose maintainer has wandered off. The talk was mostly going to be about that, but after a bunch of conversations, I realized that I probably needed a talk of more broad appeal.

The new talk is going to be: Getting Involved in Open Source. This is going to be both a personal journey, as well as a list of lessons along the way. The successes and failures are going to be basically mine alone. After over a decade working in open source, I’ve got bumps and bruises all over the place, but fortunately no mortal wounds.

I’ve already got slides and talking points spinning in my head, things I haven’t thought about in years. This is going to be a really fun talk, and should be very educational to people with all levels of open source development.

Emacs Tip: Make CSS mode sane

The default CSS mode in emacs does very funny things with indentation if you like leaving the brace on the same line as the definition. As with everything in emacs, this is fixable with a few lines of config. In this case:

 ;;; Fixes totally weird default css formatting.
 (require 'css-mode)
 (setq cssm-indent-level 4)
 (setq cssm-newline-before-closing-bracket t)
 (setq cssm-indent-function #'cssm-c-style-indenter)
 (setq cssm-mirror-mode t)

I can’t remember where I found this on the internet, but here it is, repeated again, so more folks can find it.

Steve Yegge and the Google Platform issue

Steve Yegge is one of the most insightful people on the internet. I was really bummed when he stopped blogging, because his posts were always well thought out, funny, and really got to the heart of some key issues in software development.

Last night he posted publicly, by accident, Google’s current biggest issue, a complete lack of a platform. He’s really dead on.

I hope Google internalizes that post and does something about it.

Small Wins

Really interesting post about Google Wave from the inside. My favorite passage is this:

And this is the essential broader point–as a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them.

That matches up quite well with my experience. A series of small wins keeps the team momentum running strong. Nothing breeds success like success.


Revitalizing a software project

I became one of the co-maintainers of the epublish drupal module this year, as we are an active user of it at the Poughkeepsie Farm Project, where we use it for our newsletter. I had about 6 big fixes to it that we needed, and so I was eventually just added to the project so I could commit them myself. Since then I’ve tried to clear out some of the backlog of issues, and added a few features.

In doing so I realized how fragile some pieces of the code were, as I broke things pretty regularly. Fragile code is the biggest inhibitor to innovation, because no one wants to try anything exciting and new when just keeping things working after simple patches is so exciting (and not in a good way).

So I decided to take on the project of revitalizing the code, in a couple of steps.

Add Automated Tests

Drupal has a framework called SimpleTest that lets you include automated tests in your code. These tests simulate a non javascript browser, much like using mechanize in ruby. There are also a lot of convenience functions for testing the results. In Drupal 7 this is a built in, in Drupal 6 it’s an add on module that requires a small patch to core.

Before actually making any substantial changes, I wanted to actually nail down current behavior, so that I know if I’m going to break anything. Over the past three weeks I’ve been figuring out how SimpleTest works, and writing tests for the code. I’m now up to 798 assertions, and have covered a lot of basic workflow, creating / deleting / updating publications and editions. I’d say I’ve probably got 1/3 of the coverage I should have, but I’ve ensured I’ve covered the goofy bits around article ordering that I broke multiple times in the last six months. I consider this a pretty good start.

As with all testing, the hardest part is the first test. That takes about eight hours to understand the system, and build and run a test that makes sense. I did that on a rainy Saturday before vacation. After that adding tests is easily done in 30 minute increments, which I puttered on in the mornings before Susan woke up during our vacation. In the process of getting these tests to work, I found and fixed a few critical bugs as well (when things didn’t work like they really should). Epublish 1.13 reflects these changes.

Extract the Database Layer

Step 2, which I’m starting on now, is to remove the database layer from the core epublish.module. My goal is to have no SQL statements in the core module file, and instead have those all in an epublish_api.inc file. They can be replaced with functions like “epublish_list_publications” and “epublish_add_publication($pub)”.

Again, this can be done in small increments, mornings while sipping coffee, or after work. I’m mostly looking for the kinds of SQL statements currently used, and trying to come up with the sane and well understood function name that they would map to.

Additional possible refactoring

One thing I found in doing the lending module is that it’s actually pretty nice to isolate the 3 form functions (display, validate, submit) for a specific form into it’s own include file. This makes it easy to know you are looking at everything about a transaction in one place. I’m going to see if this makes sense after the database pull out.

Theming functions also make sense to have in a separate place, they are logically quite different than other code in a drupal module, as they are the one place you’ll get markup included in the file.

New Features

All of this is really about adding a new and better interface for managing the articles in an edition, as the current interface leaves a lot to be desired, especially because of the automatically imported calendar entries we’ve got on the PFP site. It will also mean that a port to Drupal 7 can really happen. There are lots of other things holding the PFP site back on Drupal 6, but this is one of the bigger ones.

Brownfield Development

When you are a young and eager developer you always want to start from scratch on projects. The assumption is you can write a replacement in less time than it takes to figure out what the existing code does.

I’m now of the opinion that a whole sale rewrite is almost always the wrong thing to do. It means a very long period of time where you have nothing working, which means there is a good chance you give up on the project all together, with a lot of wasted effort.

This kind of incremental refactoring, adding tests along the way, lets you make pieces of the code better, and continue regular releases on existing function (even finding some bug fixes as you go). If this becomes uninteresting to me at any point, I’ll still have made the code easier to read, created a solid battery of tests, and handled edge conditions much better.

And this is how the majority of real software projects work. You aren’t there at the beginning, you aren’t there at the end. Your impact is really whether you can leave things better for the guy or gal that comes after you.

When Patents Attack

From This American Life’s latest show:

In early July, the bankrupt tech company Nortel put its 6,000 patents up for auction as part of a liquidation. A bidding war broke out among Silicon Valley powerhouses. Google said it wanted the patents purely to defend against lawsuits and it was willing to spend over $3 billion to get them. That wasn’t enough, though.

The portfolio eventually sold to Apple and a consortium of other tech companies including Microsoft and Ericsson. The price tag: $4.5 billion dollars. Five times the opening bid. More than double what most people involved were expecting. The largest patent auction in history.

That’s $4.5 billion on patents that these companies almost certainly don’t want for their technical secrets. That $4.5 billion won’t build anything new, won’t bring new products to the shelves, won’t open up new factories that can hire people who need jobs. That’s $4.5 billion dollars that adds to the price of every product these companies sell you. That’s $4.5 billion dollars buying arms for an ongoing patent war.

The big companies — Google, Apple, Microsoft — will probably survive. The likely casualties are the companies out there now that no one’s ever heard of that could one day take their place.

This American Life did a bang up job taking Intellectual Ventures to task this weekend for basically being in the mafia business. It’s a pretty amazing story, especially when they try to find one of the “protected inventors” that IV claims it helped out. Well worth listening to.