Author Archives: Martin Cron

Aug 11 2008
Leave a comment
Photography, Software

Kind of Chunderwhelmed

For my birthday (I’m now 100000 in binary) my lovely wife got me a Chumby to place in the kitchen. Specifically, it was to replace the low-quality radio that I had in there. I wanted to be able to listen to internet radio (mostly the KUOW stream) as well as view various photos from flickr.

It does both of the things that I want it to, but neither in the way I actually want.

Internet Radio

Turning on the radio consists of (1) squeeze to bring up control panel. (2) touch  “Music” button, (3)touch to scroll down to “My Streams”, (4)touch to select my favorite station. (5)touch play. Optionally, if I want to get back to the channel/widget display, I have to (6) touch “done”, (7) touch “done” again, and finally ( 8 ) touch “hide control panel”. 

Yes, that’s 1 “squeeze” and 7 touches to turn on the radio and get back to where I was. Sometimes I want to do this with wet and/or soapy hands. 

Flickr Photos

Flickr has a cool feature where you can get the RSS feed of just about any collection of photographs. You can see the photos your contacts have posted, photos uploaded to a particular group, photos tagged with particular tags, etc. It’s a very cool system. I had assumed that I could just point the chumby at a flickr RSS feed for some of my favorite groups and always get a chance to see new different things. Unfortunately, the Flickr widget doesn’t do this. Instead, I created a simple “Chumby set” in my account, and I’m using the chumby like a simple digital picture frame, looping through the same small set of pictures. It’s cool, but not what I had in mind.

What does this mean to me as a developer?

As someone who both produces and consumes software, this speaks to the difference between a feature and a use case. “Flickr Support” is a feature, while “As an off-camera lighting geek, I want to view new strobist group photos, because I enjoy getting new ideas” is a use case. “Internet Radio Support” is a feature, “as a news junkie, I would like to switch on NPR the moment I enter the kitchen because loading/unloading the dishes is a boring low-stimulation activity” is a use case.

Too often, people are thinking/speaking in terms of features when they should be thinking in terms of use cases. This is not to pick on the good people at Chumby, I think what is more likely is that they were thinking in terms of an entirely different set of use cases than I was. 

To be fair, a lot of things work really well. The chumball game is mesmerizing. The motion sensor works much better than I would have expected. The selection of clock widgets is awesome. My favorite is the death star clock. The sound quality is quite good for such small speakers. Much better than the radio I replaced with it.  I’m still planning  on writing a few chumby widgets of my own, and I plan on getting one to use as a bedside clock-radio. I’m just a little sad that this cute funky toy is so close to what I actually want.

Aug 10 2008
1 Comment
Software

Progressively More Disturbing Contextual Search Results

 

I was recently searching to see if there’s a standard/ideal way to catch the “potentially dangerous input” exceptions that ASP.NET likes to throw if there’s anything that looks like script injection in the request.

Note: these did not come up in my Google results, but in a page hosting a generally useless forum discussion.

OK, this one is kind of funny. I’ve never watched the show, but I hear that it’s pretty good. I live in Ballard and drive by the signs for the boat tour all the time. I was trying to catch “potentially dangerous” exceptions, and not “deadly” ones, however. 

 

Ignoring for the moment that our culture is already awash in meaningless catch phrases and we shouldn’t encourage people to use more of them, aren’t catch phrases free? If they somehow weren’t free, wouldn’t you be better making up your own?

 

This third one is the most disturbing. Using GPS to track someone you suspect of cheating on you? Added bonus: having an active GPS installed on someone’s car would come in handy for the post-breakup stalking phase. Here’s some free advice to anyone looking into this solution: if your relationship is so bad that you feel a need to track their every move, it’s best to move on. If you need evidence, hire a private detective, because at least that’s kind of cool.

Alas, I didn’t find anything useful with the specific problem I was searching for. I’m just turning off the request validation and dealing with the potentially dangerous stuff manually.

Aug 04 2008
1 Comment
Software

Another 25 employees? No thank you.

I recently read an outrageous claim from a company that makes software project management tools. I’m leaving the company name out of this post as I don’t want to either single them out, or to give them publicity.

[Product X] companies were 25% more productive.  That’s like adding 25 people to a 100-person department, free!

Let’s just set aside the notion that you can accurately measure productivity of software teams in a meaningful way (you can’t). My immediate thought take on that was, “No, it’s like removing 25 people from a 100-person department. Hasn’t anyone read the Mythical Man-Month?”

Jul 22 2008
1 Comment
Agile, Software, TDD

Automated Test Distinctions: The Food Pyramid

This is something I came up with a while ago when I was working on a large integration/orchestration project for a now-defunct MVNO (mobile virtual network operator). It was a pretty complex project, which had many external collaborators and end-points into the system. The project was having some issues with being able to reliably deliver incremental functionality on time. I had a directive to use my judgment to essentially turn the project around.

I had just come off a project which had excellent pure unit test coverage, but not very good overall test coverage with actual collaborators. The integration points were much more difficult and painful than they needed to be. On the other extreme, I inherited a bunch of existing non-unit tests as part of the MVNO project. These were brittle, took a long-time to run, and failed for a bunch of different reasons. As a result, they weren’t run very often, became neglected, and eventually worthless.  There was no continuous integration in place, so the feedback loop between breaking something and finding what you broke was very loose.

To make matters just a little more dicey, I was working with another test-focused developer who had a strong preference for writing epic end-to-end tests, while I was trying to make the code more able to be tested in isolation. I resented the fact that “his” tests were keeping me from running the tests as part of the cruise control build.

I came up with what I called the “Food Pyramid” as a way of balancing these different forces and points of view. I broke the one massive test project into three distinct assemblies with their own goals.  The differences between the projects are best explained in a series of pictures:

So, did it work? Yes and no. We eventually had much smoother and more confident deployments thanks to the end-to-end tests. I also managed to refactor and add new code more quickly with fewer bugs thanks to my unit-test safety net. But, just as I was starting to get a handle on the project, the client filed for bankruptcy and stopped paying their vendors (which unfortunately included me). It seems that having a viable business model trumps all.

I have, however, used these and similar distinctions successfully on subsequent projects, and I know that at least one development organization I’ve explained the idea to has adopted the pyramid as part of their overall testing strategy.

Jul 18 2008
2 Comments
Agile, Lean Software, Scrum, Software

Not Sure the World Needs Another Named Prescriptive Methodology

This, on the very same day that some tries to create a definitive list of methodologies, Net Objectives (the one-time sister company and training provider for the company I contract through) has just announced their new flavor/version/whatever of Scrum, which they are calling Scrum# (pronounced “sharp”, like C-sharp). It is (as far as I can tell) essentially Scrum + Lean Thinking + Emergent Design + Focus on scalability. Many things that a lot of us are doing already.

To be fair, the approach they are taking is exactly the one that I would advocate, focusing on and being mindful of the principles/values of what works and what doesn’t work. I’m just not sure I can get behind the name.

Jul 17 2008
Leave a comment
Lean Software

Respect for People, and Mean-Spirited Trash Talk

I was at lunch with a few developer friends a few weeks ago when a story of rather horrible code experience came up. Someone mentioned that they should send it to The Daily WTF.

“I don’t really like The Daily WTF.” I said, off-handedly.

Everyone looked at me as if I had said that I didn’t like kittens, or apple pie, or democracy.

“What?” one of them asked.

“I think it’s too mean-spirited” I said, lamely.

I didn’t always feel this way. My position on code-quality-improvement-via-harsh-mocking changed after working with a great developer (the kind that reminds me that I am merely a good developer). He was very focused on code quality and would say things like “I should hop on a plane and fly to where this guy who wrote this is and punch him in the nose for writing this method this way” or just cry out “Jesus Christ!” when he found something that he didn’t like.

Even though we always got along, it made me nervous. If this is what he’s saying about other people’s code, what’s he saying about my code? It created a sort of climate of fear. Not only that, it didn’t do any good to actually improve the codebase as a whole. We still had a team member who insisted on writing things in his own way. He brushed off valid concerns as “well, that guy just hates everything”.

This culture of harsh criticism is what leads people to be generally closed and insecure. Personal example: I thought about releasing the source code to my little Survival-Horror Asteroids game, but I haven’t yet, for fear of having some sharp-tongued rock star developer come along and tear me to pieces. 

None of this is to say that you shouldn’t be discerning. I’m as concerned about the distinctions between (and definitions of) good code and bad code as much as anyone else. I’ve literally had nightmares about having to work with a particularly nasty procedure. I’ve just learned to not be so insecure that I have to insult and belittle people over it.

This isn’t just a problem with developers, either. I enjoy reading about design and usability, and I found a great article about a particularly mean-spirited Flickr thread in response to a screenshot from an iPhone app. The app itself may not look great, but the developer had done nothing to warrant the vitriol of the responses. 

How to make things better:

1. Be kind and respectful, even to inferior coders. When I first read about the Lean Software Development concept of “Respect for People” I read it as “Respect the developers, especially Martin”. But it’s actually omnidirectional. Respect the other developers. Respect the folks in marketing, respect the pointy-haired-bosses (the first step, of course, is to stop calling them pointy-haired-bosses). 

2. Think incrementally. If you’re working with a developer who needs to improve, select a few distinct values-based things that need to be changed when you provide feedback.  If you try to fix absolutely everything all at once, you’ll fail.

3. Be constructive. Comments like “my eyes bleed” or “you, sir, are too stupid for words” don’t help do anything besides inflate the ego of the insult hurler. Comments like “if you do an extract method refactoring instead of copy-paste, it will be easier to understand and maintain” or “some stronger lines of alignment would make this easier to understand” are helpful.  

3a. (update, July-19-08) Realize that reasonable people can have different opinions and pick your battles. I’ve stopped getting hung up on stylistic things such as formatting or casing. I’ve learned to adapt to the consensus of the project. It’s a useful skill.

Also, realize that there’s generally no one right way, most things are tradeoffs. In this de-normalization example, the author is looking into trading one kind of pain (arguably slow joins and more complex queries) for another kind of pain (risk of data anomalies). It’s generally not the tradeoff that I would make, but it surely  doesn’t warrant the “you have no business designing databases” hate that he got in the comments. 

4. Realize that mistakes are OK and a necessary part of progress. Some developers (including me sometimes) get defensive or insecure when people find bugs in their work. The best developers I’ve worked with never are. It’s not that they never make bugs, but they don’t take their bugs personally.

Jul 03 2008
1 Comment
Software

Is Clearwire right for you? Take this simple quiz!

Alas, the curse of the early adopter.  I was really excited to switch to Clearwire, especailly after my beloved ISP for many years, Seattle’s own Speakeasy Networks was purchased by Best Buy. I’m not exactly a Best Buy fan.

I should have done some more research before signing up, though. It turns out that Clearwire is actually not for everyone, and the things they don’t support well are not really called out in the terms of service. To help future consumers, I’ve put together a simple guide:

 

Clearwire is not for you if you’re a pirate.

Intellectual property pirate, that is. I think that the company has no problem with peg legs and eye patches. Reading some reviews online, I found that ClearWire openly and aggressively throttles traffic from P2P apps such as BitTorrent. No big deal, I almost never use BitTorrent, and I never ever pirate movies, software, or music. 

 

Clearwire is not for you if you want to watch perfectly legal web video.

Sure, BitTorrent is used largely for piracy and/or pornography, sure the copyright status of YouTube videos is often dicey, but what about Hulu? Hulu is the Republican National Committee of web video, as square, legal, and business-friendly as it gets.  Hulu also provides some of the most conclusive proof that My connection is throttled, as I can reliably watch the first half of an hour-long drama no problem, but the second half is unbearably slow.  Letting me watch the first half of a really engaging show like House but not the second is just mean-spirited.  Now I’ll never know if it was Lupus, Vasculitis, or Paraneoplastic syndrome!

 

Clearwire is not for you if you want to listen to internet radio.

OK, maybe streaming video is too much to ask for even if the video bitrate is well within the download bitrate I’m paying for. How about streaming audio? Well, if I’ve been doing anything network-intensive in the last few hours, the live audio stream from my favorite NPR station to my Chumby stops working.  

 

Clearwire is not for you if you’re a digital photographer.

Every time I try to upload more than a dozen or so pictures to Flickr via the Uploadr, I hit whatever mysterious upload cap there is and the last of them just completely fail with the “Houston, we have a problem” error message. Just like with Hulu, it works fine for a little while before some opaque limit is hit and then it grinds to a halt. How important is this really? It’s not like very many people actually use Flickr.

 

Clearwire is not for you if you need to work from home.

After several years of working from home exclusively, I try not to work from home any more than I need to, but when I need to make a  VPN/Remote Desktop connection to my PC at work, it works out pretty poorly. I know the problem isn’t with my company’s network connection, as when I do VPN/Remote Desktop from a coffeeshop with Wi-fi, it’s like I’m at my desk. Maybe this is meant as some sort of feature? Helping me improve my work-life balance? 

 

Clearwire is not for you if you’re a Linux user.

As linux users tend to be power users who not only download huge ISOs, but also download ISOs using the infamous BitTorrent network. Fortunately, for me, I haven’t been a Linux user for some time.

 

Clearwire is not for you if you’re a Mac user.

This was particularly painful. The first day with a gorgeous new iMac, some software I wanted to run required a large OS X update… which by the end of the download, was coming down at sub-dialup speeds. 

 

Clearwire is not for you if you’re a Microsoft Windows user.

Even more painful and disruptive to download than the OS X updates are the frequent, vital, and huge updates that Windows XP needs.

 

Ouch. That has turned out to be a very negative summary above, and I usually try to be a positive person. So, who would Clearwire be ideal for? Here are some groups of people that I can think of for whom Clearwire would work well enough:

  • The last holdouts of the gopher protocol, those who are convinced that this whole web/multimedia business is just a passing fad. 
  • People who want high-speed internet but don’t actually have any computers or network devices.
  • Dead people.
Jun 30 2008
Leave a comment
Agile, Lean Software, Software

Agreement on the Lean-Agile Connection

I’ve been arguing (mostly unsuccessfully) for some time that Lean Software Development and Agile are two different intellectual frameworks for understanding the same underlying concepts. The artificial distinctions that people draw are often based on connotations of the words themselves, such as “agile is about fast while lean is about cheap”.

Now, in a shameless appeal to authority, I find that Martin Fowler sees things the same way. From a recent post:

You can’t really talk about them being alternatives, if you are doing agile you are doing lean and vice-versa. Agile was always meant as a very broad concept, a core set of values and principles that was shared by processes that look superficially different. You don’t do agile or lean you do agile and lean. The only question is how explicitly you use ideas that draw directly from lean manufacturing.

Right on!

One thought on drawing ideas directly from lean manufacturing: The ideas that work in both manufacturing and software (such as empowerment, incrementalism, tight feedback loops) don’t necessarily work in software just because they work in manufacturing. That’s a naïve mindset that can lead you to all sorts of bad conclusions.  Some ideas work in both due to the nature of the people involved in both. 

It’s easy to get ideas from manufacturing as it’s a human endeavor that’s more mature and has been very well studied and documented.  An observant and mindful person could surely draw lessons from all sorts of places.  It’s possible that someday we’ll all understand software development well enough that we won’t need to borrow concepts from other disciplines. It’s clear to me that we aren’t there yet, though.

← Older posts
Newer posts →