My first smartphone was a Windows Mobile 6.0 phone (bought months before Microsoft declared Windows Mobile 6.x an utter dead end), and eventually an iPhone.  But not the first iPhone.  Or even the second iPhone.  Why?  Because, as groundbreaking and powerful as they were, my research determined they were missing certain key features that I needed to do what I want, and being a relatively closed and restricted environment, those features were not going to be added on by someone else.  I did my research, and said “Not soup yet”.  How do you release a device you say surpasses anything else without cut/copy/paste??!?!?  I am very much NOT an Apple Fanboy, but why, being a Linux Fanboy, would I not go with an Android phone?  because (1) At least at the time, you couldn’t back up or sync any data with an Android phone without surrendering all your contacts, schedule, etc with Google, which is an unacceptable privacy violation to me, and (2) AT&T had modified the phones to be even more locked down than the iPhone!!!  But I wold not have known that if I just simply said “The Linux-based phone must be more open, so let me get that one”.

When the Kindle Fire was announced, I started thinking about getting that device, or something like it (7″ form factor Android device around $200 with a high quality display).  Days later the Barnes and Noble Nook Tablet was announce to be available for sale a week after the Kindle Fire, and I quickly narrowed down my choices to these two.  But the rumors and predicted specs on review sites differed enough I knew I had to wait until they were available and I could play with them.  I ended up developing a detailed, objective comparison between them, and the Nook Tablet won handily (for me. YMMV).  I got active in the Nook Tablet “hacking” community, and even started working on a wiki site on it. My research found that the boot loader was heavily locked down, and while there’s a lot of hacks to load other software and markets and customizations for it, it’s unlikely that a completely new ROM would be loaded on it any time soon.  I was OK with that, because while I wanted to do much more than originally intended with the device, I still wanted it to function as an ereader, too,

I noticed, long after the word had spread that you couldn’t [yet] replace the ROM as you could in its predecessor, that people were buying them and discovering this after the fact, and returning them.  These people had bought this device for $250 or more hoping to load the latest version of AndroidOS on it, use bluetooth keyboards, hook up external hard drives to it, and Skype their friends with it, without spending half an hour finding out whether any of this is possible (none of it is yet, though Ice Cream Sandwich is close)!

This leads to unhappy geeks.  Geeks and hackers, as a group, tend to expect the world to work they way they want it to, or at least be configurable to.  Only big corporations aren’t always on board with this.  In the case of the Nook Tablet, B&N had to lock the tablet down more than its predecessor in order for Netflix to allow streaming on it.  After the security vulnerabilities came out that allowed us to gain root access to the Nook Tablet and load software from wherever we wanted on it, B&N pushed an update to the software that closed those security holes, and that update got installed on Tablets with no warning, and certainly without consent.  There was an endless barrage of flame wars complaining that B&N should not have done that, and “how dare they”.  I would calmly point out each time that B&N was operating in their own best interests (protecting their relationship with Netflix and other companies), and it’s silly and unrealistic to expect B&N to act against their own best interest to enable a small group of people who will never buy books, movies, or apps from B&N to have their fun, any more that one would expect Apple to allow Adobe Flash on the iPhone or Ford to allow you to connect your computer to the diagnostic interface of their cars with a simple USB plug.

So here’s my message: When you’re planning on buying some sort of complicated and/or expensive item:

1. Make sure you’ve identified exactly what you want to do with it (establish acceptance criteria).  This not only helps you with your research, and help determine when you’re done with it, but it can prevent you from falsely claiming you’ve found “the perfect solution” if you really haven’t.  It also helps convey to others what you’re looking for.  Be honest with yourself.
2. Make sure you’ve made a reasonable effort to identify all possible items that could meet your needs.  “Premature optimization and/or filtering” can lead to excessive narrowing of the result set.
3. Make sure you look at both the good and bad features of each item, identifying any deal-breakers.
4. If you absolutely need a feature, and the device doesn’t have it yet, don’t assume that it will be added in the near future, or ever.  Even barring external influences like regulations and partnerships, their idea of the future of the device may be very different than your own.
5. If you can afford to wait even a week later, you will benefit from the experience of the others who were not so thorough.  Learning from other peoples’ mistakes is much cheaper than learning from your own.  Learning from other peoples’ successes can save you hour of research.
6. If you can’t find evidence either way whether the device can do what you want it to or not, don’t be afraid to ask.  And ideally, spread the new knowledge.

©2012 /home/dkramer. All Rights Reserved.

It’s often said that a broken watch is right twice a day (the joke presumes a mechanical  analog watch).  With a complex processes involving lots of parties like software development, misinformation can be much worse than no information at all, because you don’t know what you don’t know, so you make plans based on lies.  Here are some bad practices to watch out for:

• The list of requirements must be complete when the iteration begins.  Significant changes to requirements inside an iteration invalidates all the planning that went into it.  In my current day job, we’re trying to prevent this by having the UI team develop mock-ups and have them approved the sprint before the work is to be done.
• The list of tasks for a story must be complete and fully described.  I have seen iterations destroyed just because the planners forgot to task out creation of test data.  I’ve also personally experienced work stoppage because a task was insufficiently defined, and the stakeholder with the details was out of town.
• Done has to mean done.  And Done has to include the code being checked into source control, QA testing what’s in source control, and ideally integration tests.  The mindset of “It compiles, so let’s ship it” creates the worst kind of technical debt.

When I compare Agile to Waterfall to people with no Agile knowledge at all, I often compare a torpedo to a boat.  A torpedo will usually get to where it’s going quickly, but if the target moves (market changes, company changes focus, customer changes focus), or if anything does go wrong (available resources change, regulatory changes), the torpedo is most likely not going to be very effective.  It’s pretty “fire and forget”, so there’s no way to change course, or even tell that it’s no longer heading towards where the target now is.  A boat, on the other hand, moves slower than a torpedo, but is steerable and even stoppable.  It may (or may not) take more time to get where it’s going, but when it’s done it’s much more likely to be where you need it (the product does what the customer currently needs, whether that matches what the original goal or not).

If the pilot of the boat doesn’t know where the boat is or how fast it’s going, it can end up anywhere,  and just like the torpedo, the pilot won’t know until it’s too late to correct the boat’s course.

I’ll leave you with a real-world example I experienced.  A previous employer of mine developed a very large product that was really a platform to build applications from.  Each customer needed very heavy customization to make it suit their needs.  The product was designed to be that flexible.  The problem was that this process could take seven months or more before the system could pass user acceptance and we could get paid.  The company decided the solution was to develop several application templates for different target markets to use as a starting point to greatly speed up deployment.  That sounds like a sensible solution, right?  The problem is they spent more than $600,000 and close to a year to decide what those templates should be (you read that right, that’s just the market research to figure out what they should be, not the coding to develop them).  In that time, the market had totally changed, and their results no longer matched what their potential customers would need.

©2012 /home/dkramer. All Rights Reserved.

Take the aforementioned Anthony Bourdain episode.  He was in Haiti in one of the poorer areas.  He came across this woman selling food on the street.  Anthony noticed her sales were very low and she had too much food, and also that there were many hungry kids around that had no money to buy food.  He talked to the producer, who authorized him to buy her whole supply at full-price and give it out for free to the kids.  Win-win, right?  Wrong.  What ensued was massive fighting over the food, with kids whipping and beating up other kids over who would get the food.  In the end the strong and violent ones got the food, not the most needy.  I’m not trying to criticize Haiti, or even human nature, but point out an example of big change having unintended consequences that helping on a smaller level might not have had.

The book Switch contained an example of a health organization trying to decrease malnutrition in Vietnam with almost no budget and very little cooperation from the local government.  Instead of trying to solve the problems of food distribution, clean water, safe waste disposal, and hygiene, they did a study of what was different about the poor families who were not suffering from malnutrition, and spread those practices (it turned out that doing small changes like feeding kids the same amount of food but four times a day instead of two, and adding a little bit of crab and vegetable to their rice, was enough to make a huge difference).

Here are some personal examples:

• At a recent job, our software build system was “a bit finicky”, required several steps to do common tasks, and required the same command line parameters again and again.  I could have lobbied for changing the build system, but there was political/emotional commitment to keeping it the way it was.  Rather than tilting at windmills and not getting anywhere, I developed an environment that wrapped those commands, putting all the required steps into simpler commands, and reading the required parameters from environment variables.  I then advertised it and helped others use it too.  Immediate benefit for myself and others, without the political casualties.  At that same job, I spent a fair amount of time documenting what I learned on the intranet wiki as I learned it (I was the first developer they hired in years, so there wasn’t a culture of documenting things the newbies would need), so others that came after me wouldn’t have to go through the same discovery process of mind melding with the Elders.
• At my current job, our cafeteria uses disposable Styrofoam trays and cups, plastic utensils, and cardboard plates.  In order to reduce my ecological footprint, I bought a plastic tray at Target for $2 and brought in a plate and metal utensils from home.  I just did this a week ago, so nobody has done the same yet, but several have stated that they want to.  I could have petitioned them to switch to plastic trays and real plates, but even if they were willing, they don’t have the facilities or manpower to wash them all.  Instead of waiting for that big change, I am doing what I can now, and leading by example.  I also turn my monitors completely off overnight (the computer has to stay on in case I need to remote in from home).
• I tend to tip big.  I’ve worked in the restaurant industry (both in corporate and in the restaurants), and understand what those people are going through.  Most people don’t even know their salary is minimum wage less their expected tips.  Yes, if their customers tip poorly, they can make less than minimum wage.  Having been blessed with the desire and ability to work in the software industry for a long time now, I try to spread the wealth a bit.  Sorta like Robin Hood, but I’m stealing from myself
• Before donating to charities, I research just how much of the money goes towards the cause.  You would be totally shocked if you found out how much money went into just running some of the very large, very popular charity organizations out there.  In fact, some charities even spend money suing other charities.  Others don’t actually spend that much on solutions to their cause.  Do your research to make sure your money goes to what you want it to.  Or help directly.  That’s one reason I tip big.  Anyone working in a customer-facing service industry job needs help, even if it’s a little.  Even if it just makes up for those that don’t tip well.
• I volunteer for four different not-for-profit groups (one related to helping unemployed people, one related to Agile software development, one related to Linux, and one as part of my religious institution).  There are many reasons why getting involved with groups like this can benefit both you as well as the group (networking, new knowledge and skills, sense of accomplishment, etc), and these are all communities I feel strongly about helping.  All of these groups are trying to help others in the small ways that they can.  In many ways, the unemployment group is much more helpful than the federal or state groups, because they focus on people helping each other and giving out fishing poles instead of fish (small amounts of money the Division of Employment and Training are going to give you for training is not going to do as much good as a group that helps you handle tough interview questions and polish your elevator speech).

Maybe the tendency to do small changes now instead of waiting for big changes comes out of my Agile background, with its short iterations and active tracking of blockers.  Maybe it comes from my strong tendency for action over inaction.  Or maybe it’s just because I’m an impatient New Yorker.  Most of the time, though, hindsight has shown that course to be the right one.  So please, if you want to save the planet (or just your family, your job, or your sanity), strive for small changes you can do today.

©2012 /home/dkramer. All Rights Reserved.

Visual Work

When I started doing more serious page layouts, I though that I was back working in HTML with table layouts.  Great.  Then I remembered the problem of using tables for layout in HTML wasn’t the mechanics of it, but the semantics of it.  Tables are for representing data in columns, not laying things out on a page.  The Flex containers are designed for layout, so it “makes more sense” to use them for that.

The properties of these containers used to shape and align these containers and controls can be quite confusing and inconsistent, but they are powerful.

The Language

The programming language behind Flex and Flash is ActionScript.  In fact, FlexBuilder compiles Flex down into Flash and ActionScript, which is why it can be played in the same exact Flash Player.  As a Java developer who spent a lot of time with Perl, PHP, Python et al in the past, it frustrates me to once again be working with weakly-typed variables that can contain anything you can imagine.  It makes runtime debugging a necessity.

Objects in ActionScript are like associative arrays (Map<String, Object> for the Java folks out there).  When you declare an object to be of a particular type, you can think of it as creating an array containing certain properties, some of which are functions (methods).  What happens after that is anyone’s guess, as properties can be added and taken away arbitrarily.

Scope rules in ActionScript are like “frontier justice”.  You can declare a variable inside a for loop, and it will still be there with its last value outside the loop.  At least packages work in a way you would expect.

Connection to the back end

Flex actually does shine here, for the right combination of front end and back end.  Adobe made it pretty easy to pass serializable objects between a Java back end and a Flex front end.  A layer called AMF deals with most of the messiness, but there are gaps.  For instance, since ActionScript has no concept of enumerations, they kinda haveta be faked.  There are also several MVC frameworks if you’re into that kind of thing.

Quality

FlexBuilder, the IDE, is built on Eclipse.  It’s not bad, but it leaks memory like a sieve, so expect to shut down and restart it once a day.  The real quality problem is in the SDK itself.  I’ve run into many situations where the debugger stopped at an error in the SDK code caused by poor quality code that didn’t verify whether operations succeeded or expected parameters were really there.  Some of the most basic objects, like List, are the worst offenders.  I spent about four hours today just trying to get a List to sort.  Never got it working.  We’re using a tree control at work that has four bugs reported against it because we haven’t figured out how to work around the underlying tree’s limitations and bugs.

Portability

You can look at this from two different angles; portability from a developer point of view, or portability from a user point of view.  From a Developer point of view, the picture is not pretty.  Adobe had a beta version of a FlexBuilder port to Linux.  They’ve since abandoned the effort, leaving cross-platform developers in a pinch.  I believe the SDK still runs under Linux, but with no IDE it would be difficult to develop new software using it.  Personally, I’m very surprised they gave up on a Linux version, given how much there is to gain by doing so.

Conclusion

For real complicated applications, unless there was no other practical ways to do what you want, I would stay away from it.  Other than that, it’s worth a try,    But given the capabilities of modern-day JavaScript libraries, and the promising features in HTML5, I would have to think hard about recommending going this route for everyone.

©2012 /home/dkramer. All Rights Reserved.

Just as exciting, next week is our Agile Games 2011 event, which is almost sold out.  There are four or five tickets next.  What is it you say?

The Agile Games conference is an exploration of how concepts like serious play, collaboration, and experiential learning apply to the field of Agile software development and project management. Our theme for this year is “Learn. Share. Play!” More than a conference, this will be an experience where attendees will be able to learn new concepts, then immediately share and experiment with other professionals. Forget death by PowerPoint. Every single session we offer will be interactive, hands on, and – dare we say – fun! Whether you’re new to Agile, a capable practitioner, or a seasoned veteran, this conference has something for you.

This promises to be a great event for people at all levels.  If it interests you, sign up soon.

©2012 /home/dkramer. All Rights Reserved.

Since my last post, I’ve started about six posts that I never finished because I just wanted to add this one last point, or tweak that paragraph one more time.  The result was no visible work output, which is inexcusable for an Agilista.I hope to change my ways here as I have at my day job.  Everything I do has to be at the request of the Product Owner.  That’s the balance of power; we the developers dictate how long each story will probably take and how they’ll be implemented, and the product owner dictates the priorities and acceptance criteria.  But focusing on the high priority tasks and knowing when to stop are hardly Agile-specific concepts.  Here’s some more reasons why it’s so important:

• The more you do, the more opportunities there are to do wrong. Statistically speaking, the more software, the more bugs.  The same goes for building houses and first dates.
• Spending time on things that may not be needed means you’re not spending time on things you know are needed
• Even if you will eventually need the unplanned features, you may have forced yourself into a particular implementation that may not turn out to be the best one in the end.  In an Agile project, you’re constantly learning more about the requirements, making more implementation decisions, and getting more feedback from the product owner.  That’s why Agile preaches making decisions as late as possible.  The essence of Agile is expecting and accepting change.
• Even if you have time to do the extra work, there may be higher priority stories to do first.

There.  I did it.  Guess I’m done!

©2012 /home/dkramer. All Rights Reserved.