-
Get a monthly update on best practices for delivering successful software.
A few weeks ago, I wrote about the Skype Video Phone, part of a trend towards trading needless complexity for simplicity and ease of use. It's also on the wrong side of another trend: The trend away from single purpose mobile devices to flexible mobile platforms.


For a while there was a trend towards more and more purpose built digital products, from ebook readers to portable picture frames and pocket size digital cameras, all the way to recipe, to digital recipe readers ($299), to tablet pcs with tough cases, handles and barcode scanners for the medical industry.
The iPhone, the iPod Touch and the soon to be launched iPad signal a reverse of that trend. Apple has designed and built flexible platforms that combine the ease of use and simplicity that single purpose devices with the flexibility of general purpose devices, and that is proving to be a compelling value proposition.
On the iPad, for example, you can easily get as good or better a recipe reader experience as you would with the demy digital recipe reader, a better digital picture frame or slide show experience than with a digital picture frame, likely as good or better of an ebook reader experience, and likely as good or better of a bar code scanning medical tablet experience.
How is that last possible, when the iPad does not come with a bar code scanner? The solution will likely be through peripherals built into functional cases. As an example, take a look at the digital checkout devices like Apple's own EasyPay touch (used at Apple's retail stores), Verifone and Morphie - that combine a magnetic card reader, a bar code scanner and a battery in a case for an iPod touch.



And of course, when the video enabled iPad finally comes out, it will likely replace the Skype Video Phone that my parents so love.
Topics: ease of use, iPad, iPhone, Kindle, Mobile, purpose built devices, simplicity

Tiling a Polygon
One of the most challenging problems I came across working on a .NET PDF Annotator and Editor application was to tile a 2-D polygon and also accurately determine the number of tiles that fill the surface of the polygon. The tiling part was not as much of a challenge as the counting part. The tiled polygon was to be rendered on a PDF document since the application in question is a PDF Annotating and Editing tool. We looked for anything the third party .NET PDF rendering/manipulation API that was used could provide for the tile rendering but there was nothing unfortunately.
So we set out to use C#'s native GDI+ library to render the tiles for the polygon. After trying out different approaches to accomplish the rendering of the tiles, we discovered the one that would work best. The idea was simple. Every 2-D shape on the drawing surface has a bounding rectangle that encloses the shape. Starting from the top left bounding point of the rectangle, iteratively render a rectangle (tile with whatever length and width) across the X axis until the right most edge of the rectangle and this iteration needs to happen over the Y-axis (not sure if I explained clearly enough
. So now we have rectangular tiles laid out across the bounding rectangle for the polygon. GDI+ gives us a clip method that allows us to clip the rendering surface to a specific graphics path or region. Using the clip method, clip the drawing surface to be the graphics path for just the Polygon so that only tiles within the polygon's graphics path get rendered on the screen. We could apply other transformations to the rendered tiles like offseting, rotation or a gap between each tile.
Coming up with the most efficient way to count the number of tiles (including partial tiles) was a little trickier than rendering the tiles. It turned out that the ideal approach was to essentially count each tile as it was drawn and checking whether the tile was partially or fully part of the polygon's graphics path/region. So, there is this method Region.IsVisible that lets you test whether a rectangle is partially or fully contained within a graphics region. During the rendering of each rectangular tile, the method was used to check whether the tile was going to be part of the region associated with the polygon and was counted if it was going to be. Even though, this was the most efficient solution for the problem, we did nt see 100% accuracy sometimes when rotation transformation was applied to the tiles. Still havent found an answer to this anomaly.
Topics: .NET, C#, Drawing, GDI+, Window Forms Development
We've discussed the benefits of Agile development before and that the iterative approach to building the architecture -- where you explore architectural issues (very few apps are completely new and unknown) a little bit through each iteration -- is an effective method for arriving at a good application architecture. What is less obvious is the psychological benefit to working in this way.
It's frankly been a while since I've participated in a large waterfall project directly (one benefit of working for a firm that does agile software product development), but I regularly talk with folks who are still in the corporate trenches doing things the old fashioned way. One thing that hasn't changed is the BIG ARCHITECTURE wrestling match up front. Management wants to know the architecture, the guys with "architect" in their job titles want to know the architecture (so they can criticize, natch), the project manager(s) want to know the architecture. How will we scale? How will we ensure security? More useless brainpower is spent on this ultimately fruitless task -- solving problems that end up being no problem at all -- than almost any other activity in the project.
Topics: agile, Divide and Conquer, Stress, waterfall
Sphinx (and its rails plugin thinking-sphinx) is my choice of search engine on ruby/rails project. It is powerful yet super easy to setup.
However, testing Sphinx code is not easy at first. Since Sphinx works by leverging database commit hooks, it cannot be tested within the bounds of unit testing framework that rails provides. This is understandable because, in rails testing, a transaction is started before each test that is bound to rollback after the test is finished. Since the test data is never committed, sphinx doesn't get a chance to index anything and cannot be tested.
The documentation for sphinx testing suggests using cucumber for integration testing. To me, cucumber test are still miles away from the smallest piece of sphinx code (inside Model) to be tested. So, I turned to how transactional code is tested in rails framework for some cue.
Here is what I ended up with:
class TransactionalUserTest < ActiveSupport::TestCase // any transactional test needs to have this self.use_transactional_fixtures = false context "with no users in database" do setup do // clear the existing data for our test - not sure if this affects other test but we use machinist instead of fixture files, so we should be good here. User.destroy_all UserProfile.destroy_all end context "with a few users created" do setup do @john = @david = nil // any data for sphinx test should be wrapped in transaction so sphinx can see these changes User.transaction do @john = User.make(:first_name => "John") @david = User.make(:first_name => "David") end end should "find user with first name john" do // start sphinx server ThinkingSphinx::Test.run do // give sphinx an opportunity to index newly added data (required before calling search) ThinkingSphinx::Test.index assert_equal([@john], User.search("john").collect) assert_equal([@david], User.search("david").collect) assert_equal([],User.search("cheese").collect) end end end end end
Isn't it nicer to be able to test sphinx code in isolation
I remember my first real grownup and serious web project outside of the university environment. It was 1994 and SSL was a novelty. People were making insane predictions that one day up to $600 million (think Dr. Evil) worth of consumer goods would be sold on the web worldwide. In 2007, just Canadian B2C sales were US$12.9 Billion.
Some folks, especially startups and smaller companies, saw the web as an opportunity to shake up the established order and establish a new sales channel or an entirely new business model. They invested what they could in building the first of what became known as e-commerce sites. Among established players, and some more conservative smaller players, there was initial hostility toward the new medium. When in 1994 I proposed to Ameritech (now part of SBC/AT&T) that they bring their lucrative print yellowpages online, I was run out of Hoffman Estates on a rail.
A friend of mine from college is a physics professor who does a lot of stuff with the space station and the new Google Lunar X Prize, that awards up to $30 million for the first non-governmental organization to land a robot on the moon. He likes to get his students involved and has a gift for expressing things in terms they can immediately grasp. "The robot," he tells them, "can be small. Think of an iPhone with wheels."
When something has penetrated the collective consciousness the way the iPhone has, it changes the way we look at what is possible.
Topics: Google X Prize, iPhone
A while back I looked at the Vaadin Plugin and tried to make it work with the Multiton PureMVC. Back then I proposed the following code:
public static ApplicationFacade getInstance() { if (instance == null) { // nuke the multiton so we can do the grails recompile if (ApplicationFacade.hasCore(CORE)) { ApplicationFacade.removeCore(CORE); } instance = new ApplicationFacade(CORE); } return instance; }
A little more noodling and you'll see that doesn't work. In a multi-session environment, each user will need his own core. Furthermore, inactive cores should be harvested, otherwise we will have a memory leak.
Continue reading »
Anther interesting item from yesterday's earnings call:
Over 90% of iPhone apps are approved within 14 days of submission.
Given over 100,000 apps in the store from a wide variety of developers (from amateurs to experts) and a wide variety of topics, that's actually pretty good. Apple claims that most rejections are actually for bugs in code, which makes sense given the wide disparity in development quality and test coverage.*
* For example, are you testing your software for ipod touch as well? You should - applications have been rejected for working on the iPhone, but not the iPod touch.
Topics: ap store, iPhone, ipod touch, Testing
This morning I sat through two pitches by two startups looking for funding. I won't get into the details, but they both had clever ideas at their root. But while one company was attractive and poised for success, the other was mediocre and not getting much traction. Why was that? They both had clever ideas, no?
Over the years I've looked at a lot of business plans for Venture Funds. The first lesson that I learned was that cool ideas didn't equal successful companies. While I would get all hot and bothered by a particularly elegant software solution, the VC's I was consulting to preferred the plans that understood the market and the customers in it (and had a kick ass management team, natch).
Continue reading »
Topics: User Modeling, Venture Capital
Academic research is incredibly inefficient when it comes to producing products and services. Grad students, post-docs and professors work on "problems" that some collection of graybeards has deemed "interesting." Their "solutions" -- sometimes successful, sometimes not -- are published as research and then, occasionally, if the stars align, is turned into a product or service through the application of venture capital via a startup.
The only thing less efficient in producing innovative products and service is the corporate R&D department. In most places you have a phase-gate process (waterfall under a different name) of conceptualization, feasibility testing, definition/specification, development and launch. They are typically bloated, bureaucratic monstrosities with huge documentation requirements and endless committee meetings that do more to stifle innovation than promote it.
There is a way, however, of applying Agile principles to the concept phase, and it relies on two of the basic tennets of Agile: failing fast and self organizing teams.
Topics: agile, Innovation

As January 26th, the rumored date for Apple's rumored tablet unveiling draws near, the hype and anti-hype keeps getting more and more over the top:
Five Ways Apple's Tablet May Change the World
The world doesn't need an Apple tablet, or any other
and the inevitable
3 Reasons A Microsoft-HP Tablet PC Would Trump Apple
If you want to keep up to date on the rumors, Gizmodo has a regularly updated run-down here.
There are a couple of places that have more informed speculation and insightful commentary - I'd recommend these three in particular:
Antacid Tablet by ars technica's John Siracusa:
... There's also the popular notion that Apple has to do something entirely new or totally amazing in order for the tablet to succeed. After all, tablets have been tried before, with dismal results. It seems absurd to some people that Apple can succeed simply by using existing technologies and software techniques in the right combination. And yet that's exactly what Apple has done with all of its most recent hit products—and what I predict Apple will do with the tablet. ...
So how will an Apple tablet distinguish itself without any headline technological marvels? It'll do so by leveraging all of Apple's strategic strengths. Now you're expecting me to say something about tight hardware/software integration, user experience, or "design," but I'm talking about even more obvious factors:
• Customers - Apple has over 100 million credit-card-bearing customer accounts thanks to the success of iTunes.
• Developers - Over 125,000 developers have put over 100,000 iPhone OS applications up for sale on the App Store. Then there are the Mac OS X developers (though of course there's some overlap). Apple's got developers ready and able to come at the tablet from both directions.
• Relationships - Apple has lucrative and successful relationships with the most important content owners in the music and movie businesses.These are Apple's most important assets when it comes to the tablet, and you can bet your bottom dollar that Apple will lean heavily on them. This, combined with Apple's traditional strength in design and user experience, is what will distinguish Apple's tablet in the market. It will provide an easy way for people to find, purchase, and consume all kinds of media and applications right from the device. It's that simple.
Thoughts on what an Apple tablet should be – or not by Andy Ihnatko
Apple always asks themselves simple and stupid questions like “How will this device be used?” and “Will this be used by human beings with, I mean, arms and hands and fingers?” and stuff like that.
The iPhone UI isn’t a desktop user interface where a pen takes the place of a mouse ... which is the model that previous smartphones followed. It was designed to be held in one hand and tapped with your thumb. Occasionally you’d use the index finger of the right hand to key things in.
You want to try to figure out the UI of the RAT? Go get yourself a comic book, or any other rectangle that measures roughly 10” on the diagonal. Hold it as though you’re reading what’s on the surface.
You see the problem? Your fingers get in the way. Think about how big that surface is, too. That’s a lot of acreage to scan, looking for the right buttons to push.
While you’ve got it in your hands, imagine that it’s a sheet of thin steel. That’s heavy, isn’t it? Hard to hold up for long periods of time.
Think about how a user interface would have to incorporate those observations. Now imagine that you’ve been doing this experiment for four years and not four minutes.
That’s a very long list of observations. If you didn’t come up with a workable solution, don’t worry: I think Apple has.
and
The Tablet by Daring Fireball's John Gruber.
... The way Apple made one device [the iPhone] that did a credible job of all these widely-varying features was by making it a general-purpose computer with minimal specificity in the hardware and maximal specificity in the software. And, now, through the App Store and third-party developers, it does much more: serving as everything from a game player to a medical device.
Do I think The Tablet is an e-reader? A video player? A web browser? A document viewer? It’s not a matter of or but rather and. I say it is all of these things. It’s a computer.
And so in answer to my central question, regarding why buy The Tablet if you already have an iPhone and a MacBook, my best guess is that ultimately, The Tablet is something you’ll buy instead of a MacBook.
Gruber's a bit more gung ho than Ihnatko or Siracusa, but they both make a pretty compelling case that something very interesting is about to happen over the next year.

Topics: apple tablet, iPhone
I often meet peers who ask what Agile practices Pathfinder utilizes. From the outside we pretty much use all of XP’s practices. However, if you take a deeper look we do some things a little differently (especially how to use and calculate velocity). For Agile purists, one might question if we are really doing Agile. They would claim changing practices is slippery slope. For example, a team will start altering Agile practices to create a “home grown” version only to find they are using only some practices and not seeing the benefits they hoped for. I feel questioning if we are really doing Agile based on exactly what practices one uses shows how familiar and mature one is with Agile principals. A better question would be to ask why we changed them. Agile is not meant to be a methodology, but a set of principals. In my opinion, using things like Velocity to estimate whether a team will finish a project within a certain time frame is a hack at best. This always was hard to explain to customers. While I was reading Leading Lean Software Development I discovered something that helps. The Poppendieck’s point out that the engineering practices of Agile (TDD, collective code ownership, etc…) are solid and not likely to change. But, the project management practices implement a system on top of another system - a hack.
Once you have sufficient experience managing projects with Agile practices you should feel comfortable adapting those practices to your own teams and projects. As long as you are still following Agile principals this is okay. In general, this is what’s going on in smaller companies. Having coached a number of large organizations transitioning to Agile I can say this isn’t how they look at things. The problems start when you adapt the practices, but try to deliver all projects in an identical manner. This makes sense for waterfall-like delivery methods. But, when an organization comes up with its own version of “Agile” it can only work for the subset of projects it is tested on. Rolling this out to the entire organization as “the way” to deliver projects from them on is a failure pattern. The principals are lost and so is the adaptability of the organization. The time spent to move over to agile is immediately wasted.
Photo Credit:
kevindooley
under a Creative Commons Attribution License
... it's hard not to think about how much easier some people's lives would be (hi Mom and Dad) if they could trade technical complexities they don't care about for vastly increased simplicity and ease of use.

My parents were technically savvy enough (with a little help from their sons) to start using Skype video in their mid seventies, prompted by the arrival of grandkids halfway across the country. But for them, it was always a cumbersome affair:
1. Arrange a time to have the video call.
2. Move the laptop to the dining room.
3. Call on the telephone to tell me that they're using Skype on the computer.
4. Initiate the Skype phone call.
Needless to say, this did not happen all that often.
This past Christmas my brother got them a Skype Video Phone. They set it up with a little help from us, and when we told them to just treat it like the telephone, they got the idea. Now, they are making video calls much more frequently - not just to the grandkids, but to our cousins in Switzerland and South Africa.
They traded complexity for simplicity and ease of use, and though the skype video phone will not end up being a success on the level of the iPhone, it's already brought my parents a lot of joy, and is part of a trend towards more simplicity and ease of use. It's one major reason the iPhone is as successful as it is.
Now imagine that simplicity and ease of use in a multipurpose, always on device with a bigger screen. My parents wouldn't need the skype video phone, they'd just have that as an app on their tablet.
In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.” If you are completely new to agile and lean you the book might move a little fast for you. If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.
If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency. These companies make money to survive rather than simply surviving to make money.
The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.” A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.
Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.
Conclusion
I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.
Topics: agile, Agile Development, Best Practices

Fixtures are notorious in rails. To get around issues like brittleness and multiple file flipping to understand single test, there have been better approaches using gems like fixture_replacement, machinist and factory_girl. No complains there. In my experience, fixture are still great for one thing: loading seed data. This is because seed data is often used by many many tests and they don't change often and hence won't cause tests to be brittle. Another great advantage of fixtures is that any fixture data is loaded once and only once for the entire test run.
Rails 2.3.4 includes a new rake task for loading seed data called db:seed. It suggests keeping all seed data as a ruby code inside of db/seeds.rb file. The issue with this is this is not DRY. You have duplicate set of representation for seed data: one side of seeds.rb and one in fixture files (.yml). Keeping them in sync is a pain and all the other disadvantages that come with not having single source of truth.
Problem
To have single source of seed data and be able to load that seed data once and only once for the entire test run.