Let’s face it, we’re all human. We can’t juggle everything in our heads, and we don’t have perfect clarity on day 1 of a project. You want to get your system in place quickly, and you definitely don’t want to waste time playing imagination games for weeks on end writing detailed documentation and pixel-perfect mock-ups that will be difficult for others to understand, and could be impossible to implement.

There is definitely value in a study of business requirements, written project requirements, and simple sketched mockups, but stay high level!

The more you layer imagined details on top of other imagined details, the further from reality you get. Write down and verify your facts, sketch out your vision, and get the ball moving!

2. Keep and communicate a clear and consistent vision

It’s OK if you realize during a project that your best chance of success means a slight change in direction.

However, be wary of too many or drastic changes in direction – pause your development until you’ve re-established your vision and reconfirmed your facts. It doesn’t make sense to continue spending time and money along any direction to which you’re not fully committed.

3. Stay engaged

Don’t send your development team away on auto-pilot. They will need your help, and you will need theirs – daily communication is healthy. As each iteration goes by, they will rely on you to imagine more and more detail on top of the code they deliver. Imagining the details on top of real concrete running software is what will keep you on track towards delivering your product.

In addition, if you see something going in the wrong direction, the sooner you talk about it with the team the more you’ll be moving towards your goal.

4. Ship

It’s OK if the product is not perfect on day 1. Call it an open beta if it makes you more comfortable, but the sooner you can get your product into the hands of your users, the sooner you will start collecting valuable feedback.

Remember, don’t imagine what your users will want, find out for sure by putting the product in front of them.

Sometimes you’ll hear the idea of focusing on your “Minimum Viable Product”, the simplest product you can build that has some value to your users. How can you fully imagine this without your users’ direct feedback?

 5. Keep the feature set small

Remember the words of Antoine de Saint-Exupery, “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

It doesn’t take much effort to build something complicated, and it is very challenging indeed to build something simple. It’s compelling as the project moves forward to imagine all the extra things it could do. However remember that by and large every new feature you add will make the product harder to use, and more expensive to maintain moving forward. Be very, very sparing.

This includes incorporating user feedback. You will get a volume of feedback from your users, but don’t take it at face value. Understand where it’s coming from, read between the lines, and either discard what doesn’t align with your vision, or re-align your vision.

6. The Long Haul

Your software isn’t an island. It lives in a world that constantly changes, and as with everything it must either adapt, or fail.

If you approach the project with a single up-front budget and leave nothing for ongoing maintenance, you’re ensuring the future failure of your product – it’s as simple as that.

Some technologies will be inherently most expensive to integrate from a maintenance perspective. Right now, social platforms like Facebook and Google+ are in constant flux and products that integrate with them can carry the highest maintenance costs as they adapt to what can be weekly changes. But who doesn’t want their product to integrate with Facebook these days?

Choose carefully and with your eyes open what technologies you integrate. Some will have a far higher impact on your maintenance costs than others.

7. Have Fun

Creating software is a uniquely rewarding experience. When you can see it in the hands of your users, and they appreciate it, it is tremendously gratifying.

But also remember the journey, product life cycles can span years or decades – revisiting the path to maintain and better it should be a positive and pleasant experience. If it’s not, you’re not going to want to do it.

Everyone does their job better when they enjoy what they’re doing. Keep your vision front and centre, keep a positive attitude, treat your users, peers and developers with respect, and it will be hard not to build something meaningful.

About 4 years ago I announced I was done with fixed price projects. It was the best business move I ever made.

There wasn’t really any change in the amount of money we made on each project. But the spirit of collaboration we were able to bring to customers, stopping the seemingly constant disagreements over what was included or not included, what was a bug or not a bug, just ceased for the customers that understood what we were about. Software development became fun again, fulfilling. We have delivered much better work because of it.

Of course, the odd customer (who we’ve gotten better at purging) would still want to argue these points. For whatever reason, maybe they grew up in a world of fixed-price contracts, they’d try and turn collaboration into confrontation. Try and change the terms of our engagement.

I spend a lot of time thinking about the whys and hows of this, and I think it comes down to this – they’ve become blind to the chaos around them.

Chaos is everywhere, and builds on itself. It starts with a poorly understood requirement, snowballs into misunderstood emails and conversations, avalanches into the maelstrom of shifts in understanding.

Chaos is deceiving. It wears a mask of order and alignment. The human brain is brilliant at finding patterns, and it is so tuned to the idea of patterns that it will perceive them where none exist. Countless times, a customer has presented a requirement as a simple thing, we listen, we write it down, “this should be trivial” we think. And then through conversation and examination the mask comes off. Then we find it’s like a matryoshka doll, behind each mask is yet another that appears ordered and aligned. Eventually deep enough into the project we take apart the last piece and voila, chaos.

Real life is messy. Countless times we’ve had the conversation around the whiteboard where we’ve just scrapped a really elegant data model saying “Wow, this is awful! If only this business case didn’t exist…” We just discovered the chaos in the middle of the matryoshka.

Customers tend to get this. They know their business is complicated. Sometimes they’ve been ingrained in it so long that they’ve become blind to the ways in which it is complicated, but when things are drawn out logically they tend to say things like “Yeah, I know it’s strange, but that’s just the way it is.”

The risk in the software project lies in not knowing how deep in the matryoshka the chaos lies.

A fixed-price fixed-feature contract expects the software developer, with little to no prior knowledge of the customer’s day to day business dealings, to take on that risk and price the project accordingly. They’ll take wild stabs, based on their own prior experiences, sometimes masking it in a thin veil of reason. A fixed-price contract will never reflect the true cost of the software, you’ve either bludgeoned the business into paying more than they should, or the developer into delivering more than they could afford to (or worse, they walk away).

A target-budget contract has more of a shared risk. The customer accepts that they may not have a “complete” solution at the end, but that it was fairly priced because it cost exactly according to the work that was put into it. The risk on the part of the software developer is simply that they do their job professionally, and engage the customer appropriately to explore taking the matryoshka apart.

Over the past couple years though we’ve very much enjoyed a more holistic and sustainable approach than target-budget, but that’s the subject of another post…

Over the past several years, I have made a number of very positive changes in my life leading up to the most important life change I’ve ever made.

In a nutshell, I’m transgender and have struggled from a very young age with Gender Dysphoria – my gender identity, how I feel inside, does not match my gender assigned at birth. Being transgender is not a choice, but what you do about it is.

After two years of therapy, and a great deal of soul searching, I realized that I could not achieve my full personal potential until I began living my life authentically as a female. As a result, in 2010 I began taking permanent steps towards this end.

After August 1st, I will finally begin living permanently as Stacey Gillian Vetzal. “Steve” will cease to exist.

Initially I realize this may be a little awkward for some. For those of you who have known “Steve” for a while, it will take some time to remember to use female pronouns and my new legal name — and that’s OK.

I already live much of my life as a woman, in fact I have many friends that only know me this way. However unravelling 40 years of socialization as a male doesn’t happen overnight.

The wikipedia page on Transgender gives a great, if academic explanation of the term, but for folks close to me I keep a copy of Joanne Herman’s excellent and brief book – Transgender Explained for Those Who Are Not – for lending. Because transgender describes such a wide variety of people, it is hard finding resources that I actually relate to. I generally discourage people from using Google and the Internet at large to learn about transgender, it’s not very helpful.

Unlike many transgender folks, my life is at peace. I have an incredibly supportive family, very supportive friends, and a great work environment. Because I am an entrepreneur my transition is a bit more public than I’d have originally chosen, but when seeking personal growth it’s important to step outside your comfort zone.

The reality is I’m the same inner person I’ve always been. My interests are the same, my hobbies are the same, and my work ethic is the same. I will now simply be able to do these things with a greatly improved sense of inner peace and dignity.

I look forward to continuing to work with all of you, and welcome any questions you might have moving forward.

Often when we are asked to write software, we are typically provided with a list of “business requirements”, constraints under which we need to build it. Some of these are architectural, some are design, some are technological, some are legal or regulatory constraints, some are business goals, and some are expected features.

Depending on the customer, these constraints have received different levels of consideration. A large established business may need a tactical solution under which many constraints are imposed (you must talk to this database, interact with this webservice, solve this problem). A new startup business may have pages full of features they want, but an intense requirement to make money as soon as possible.

The problem is, that every requirements document is incomplete. To the extent that it’s often said that the most important information in it is the author’s phone number.

One reason for this problem is that often when we write, the words we put down don’t always say to everyone what we intended at the moment they were written.

Another reason for this problem is that the requirements document was written at a time at which we knew the absolute least about the project: before it has started (see Steve McConnel’s “Cone of Uncertainty”.) Invariably and despite the best intentions and utmost upfront scrutiny, it is incomplete.

In our experience, as you begin working on a project, as stakeholders and developers accumulate knowledge about the project, you discover new information and have the opportunity to clarify many things in your original requirements.

Agile and Lean Software Development tenets tell us that if we defer the decisions we make in a project as late as possible, we can make a more informed decision simply because we know more about the project. The key is finding the “last responsible moment” – an idea championed by the Poppendiecks.

The last responsible moment is that point in time when you can make the most informed decision, and when that decision can truly no longer be deferred.

So think back to your project constraints, which of them are truly constraints and which of them are decisions made in the dark?

The idea is so insanely simple, who could possibly make a good decision without gathering as many facts as they can muster?

We should all strive to be more aware of the last responsible moment, we owe it to our customers to ensure that our projects aren’t governed by decisions made in the dark.

Cannibal is a permissions framework for object-to-object declaration and querying of permissions or capabilities. It is distributed as a standard gem library through rubygems.org. You can also view the source-code at github.

So far, Cannibal has done reasonably well for us on various projects. It’s syntax could use some improvement but we believe it’s fairly expressive as it is – if you have suggestions for improvements, please write!

Basically you declare a class as either an Actor, or a Subject, or both. You do this by including the appropriate Cannibal mix-in:

class User < ActiveRecord::Base
    include Cannibal::Actor
end

class Thing < ActiveRecord::Base
    include Cannibal::Subject
end

Then you declare permissions for your Subjects. For example, if you want any User to be able to view any Thing object, but only want users with the “Administrator” role to be able to edit them, you might declare that like this:

class Thing < ActiveRecord::Base
    include Cannibal::Subject
    allow User, :view
    permission({
        :actor => User,
        :verb => :edit,
        :actor_proc => Proc.new{ |user|
            user.role == 'Administrator'
        }
    }) 
end

Once declared permissions are easy to query, and read very well:

if @user.can? :edit, @thing
    ...
else
    ...
end

As you can see the permissions() method on Subject is still a bit ugly, and is the main reason for the < 1.0 release number. I’m definitely open to suggestions on improving its syntax.

Testing coverage is not bad, though there is some duplication between our rspec tests and our cucumber tests, and there’s a ton of refactoring yet to be done, but it’s working on a couple pet projects of mine and will be going into production for a customer project or two within the next couple weeks.

Enjoy

I hear all the time from people about projects being late, features missing, broken or “I can’t believe that ever worked” code. Often this is the voice of the customer feeling like they’ve been “had”. That their developer just didn’t listen to them. And now they’re stuck with something that they didn’t want.

This is definitely the symptom of a relationship that didn’t exist or just went bad.

I have seen projects do this, even been intimately involved. Projects where the technology that was delivered was even great but the customer relationship falls apart because it missed the mark, or they became so frustrated with the process that they just gave up.

And make no mistake, it was the software developer that failed here.

I’ve said and heard this so often that it sounds cliché – but the vast majority of time spent on a software development project is figuring out what needs to be coded.

Align what’s in your developers’ heads with what’s in your customer’s head. This is easier said than done, but regular face to face collaboration is key here. Two way participative engaged collaboration. Watch for when meetings become one way. You know what I mean, one side talking and the other side nodding giving the illusion that the idea is getting across. Fix this immediately, questions are your best tool here.

If something is said at any time that doesn’t fit, don’t let it slide! It could be a contradictory requirement, an unspoken assumption, a change in motivation. Stop and talk about it, figure out where it came from. It might just be a bit of ad-lib that is easily discarded or you may need to abort your sprint and have another planning session.

Also, recognize early when it’s time to pull the plug. Sometimes a customer is so unfocused that every status meeting they’re looking in a different direction. Agile tenets tell us this is ok, they can change their mind at any point and queue those changes for the next sprint, but if they aren’t pulling in roughly the same direction every sprint you may be going from Toronto to Montreal via Boston. Maybe you should have focused on getting to Kingston first.

So, take time during a project to connect everyone. Get them talking, honestly and openly. Don’t be afraid to look like a fool because you’re not. Show your courage from the start and you can avoid the illusion of incompetence later.

For all of 10 minutes she had something that I desperately wanted, and she knew it drove me nuts

So this is day 1 with my new iPad. The 64GB wifi version.

Setting it up has been pretty painless except for one annoying thing – it won’t even open the app store on the device because it is connected to my Canadian iTunes account. Oh, and it took an hour to sync all my stuff to it.

Other than that things have been going fairly well with it. It is super responsive, easy to type on, and since the last iTunes update I have 8 apps that have already been updated for the device. I am writing this on the iPad version of the WordPress app.

With regards to buying new apps, it gets a little tricky. Of course you can’t buy apps from the US iTunes store with a Canadian credit card, so I’ve been exploring what’s available in the Canadian store. Because the iPad isn’t released in Canada yet, there is no iPad section in the Canadian store but iTunes does show you iPad apps when you search.

Searching on the iTunes store for iBook or Keynote come up blank, but I am wondering if I can justify Plants vs. Zombies HD after buying the iPhone and Mac versions

The Kindle app was already updated for iPad, but I don’t own any kindle books yet. Stanza works but hasn’t been updated yet for iPad so it doesn’t fill the screen, or is fuzzy if you do.

The WordPress app was a bit funny because there are 2 apps, both with the same name, one for iPad and one for iPhone and you can’t really tell them apart. Luckily when syncing I noted one was much larger and it happened to be the iPad one.

I’ve always been very disappointed in the Google app, and was happy for a minute to see that it has been updated for iPad. But alas, it’s nearly identical. Too bad it’s little more than a bunch of bookmarks for Safari.

Well, that’s it for now. Going to go play Plants vs Zombies – the iPhone version zoomed in – which isn’t so bad. The larger screen itself makes a tremendous difference in gameplay. The zombies are coming!

I’ve been involved as a user and as a developer in projects in the past providing intermediate tooling. That is, a software tool that produces a template or even finished code for a different software tool. From Maven archetypes for Java to code-generators for UI, from Flash generators to iKVM.

Believe me, it’s no bed of roses. About all they’ve ever accomplished is to allow someone to take what they know about Environment A and find some mapping of that to what they don’t know about Environment B.

The trouble is, the mapping between Environment A and Environment B is “lossy” – and on a platform like iPhone it’s like JPEG compression at 10% quality.

You could argue that the intermediate tooling can “narrow down” its focus to a subset of a particular problem domain. Like a game generator that builds “Sim-X” style games, you just change the calculations some and provide different graphics. Likely it could get a much better match between Environment A and Environment B by not trying to be everything to every developer.

The problem with this approach is you get a very homogenous set of Apps being published that all basically look and work the same.

Then there’s the issue of keeping the intermediate tooling up to speed with the latest enhancements in the target platform. There’s an inherent lag here because you can’t QA or sometimes even start building your tooling until that platform is in production. By then you’ve got frustrated users in the field who can’t use the features they want, or worst-case have crashing generated applications because your generator built “bad” code.

Jobs doesn’t want a bunch of crappy or duplicate applications in his App Store. I wouldn’t either. He wants useful applications with a high-quality end-user experience. Would you rather fish through a sea of 15 crappy apps to find the 1 gem in the mix that was hand-tooled from the ground up, or would you rather just grab the 1 gem and get to work?

I’m reminded of one of our favourite quotes at TWM:

“To become over-familiar with one weapon is as much a fault as not knowing it sufficiently well.” -Miyamoto Musashi

We always urge our developers to expand their base of knowledge. Every new programming language and environment they learn makes them a better programmer in all of the environments they know.

If you are so tied to one environment that you refuse to learn well any other, you are not reaching your potential and I guarantee you are producing substandard work even in the environment you feel you have mastered.

If you want an environment of useful and successful software, you don’t lower your standards to get it – you raise them.

In the mid to late 90′s I spent a lot of effort on interactive media for desktop computers and commercial television. There were promising technologies and great multimedia development platforms, and out of this open specifications emerged like SMIL (Synchronized Multimedia Integration Language) and SVG (Scalable Vector Graphics), while HTML (HyperText Markup Language) flourished.

Interactive tools were built upon the shoulders of visionary products developed in the late ’80s and early ’90s like Hypercard, Macromedia Director, and AmigaVision.

SMIL was quickly adopted by Quicktime, Windows Media Player, and Real Player – the trifecta of heavy-weight vendors with a vested interest in interactive media. It was very promising that these vendors could all gather around this common open format for interactive media.

This was at the same time as Flash was also starting to take hold in the market.

Then over the following 10 years, SMIL was virtually assassinated from the landscape.

There’s a lot that can be written about SMIL and SVG’s failure in the industry.

Quicktime X no longer opens and runs SMIL files (Quicktime Player 7 does, and it’s still in the spec). Quicktime on the iPhone won’t handle SMIL. WYSIWYG SMIL editors now are nowhere to be found. Evolution of the SMIL specification slowed to a crawl. The once potentially vibrant ecosystem around open standards has withered to nearly nothing – with obscure projects like Ambulant remaining as last-chance efforts to keep an open format available to the world for interactive media.

My problem with Flash isn’t its capabilities – they are impressive. It is with the fact that it is a vendor proprietary format, with a closed ecosystem. Adobe makes the flash player. Adobe makes the flash development tools. Sure some other companies provide streamlined development tools based on Adobe’s APIs (like SWiSH Max) but Adobe controls what they can and can’t do with those APIs.

Apple is rallying behind emerging and open interactive formats like HTML, which have recently been trying to introduce new features like Video and provide a richer standardized interactive format – strangely what the world seems to be crying for all the time we let SMIL wither and die. Can you imagine what things would be like if HTML were a vendor-proprietary format? What would the world be like if Microsoft owned HTML? Adobe? Apple? Commodore?

In HTML / JavaScript you can build basic iPhone apps that look and feel just like native iPhone apps. For years now I’ve argued that most of what you see in Flash has been available using Dynamic HTML techniques pioneered 10 years ago – and standardized and popularized years ago among savvy web developers with libraries like Script.aculo.us and jQuery.

What we continue to lack are modern versions of the great pioneering multimedia tools. Classic HTML tools don’t cut it – we need tools that average computer users can grasp, that they DID grasp 20 years ago but we seem to have lost. That a teacher can sit down and use to build an interactive aid for students. That a marketing professional can use to build an interactive product demonstration. That aren’t tied to a vendor proprietary format. That will play natively in a web browser as intended by the author.

So I say to Apple, help us remember that Flash is just ONE option in the world of interactive media. Help us to remember that websites don’t need Flash to be highly interactive and graphically rich. Help us to remember that we need tooling and support for open standards and to realize the interactive multimedia vision that seemed so clear 20 years ago.

Ignore the whining from the complacent and lazy market, stick to your guns, and KEEP FLASH OFF the iPhone / iPad!

So if you recall, I have a Maven 2 build. I now have discreet API jars isolated for JPA 2, Servlet 3, and EJB 3.1. This allows me to build with a single dependency tree for production and still provide a suitable environment for automated testing by providing EclipseLink as a JPA2 implementation under my “test” scope.

My next challenge came when I wanted to use CDI (Contexts and Dependency Injection) to start wiring up components for use in my Facelets templates. If you recall, CDI allows you to do things like name your components and place them into specific scopes (session, request, conversation, application) so that they are lazily instantiated on demand when your web templates need their services. It also provides automatic dependency injection so when your components require other components to work, they can have themselves automatically created and injected by the container.

You’d think that because CDI largely came from Weld that the API jar would be reasonably simple to isolate. Strangely however some of the annotations I need (@Named, actually the whole javax.inject.* namespace) are completely missing from the Weld 1.0.0 and 1.0.0.SP1 distributions, and they’re buried in Glassfish in the weld-osgi-bundle.jar in between all the implementation stuff.

The JSR for CDI points to the Weld 1.0.0 distribution so I’m SNAFU’d there looking for javax.inject.*, and I’ve been unable to find another useable jar out there in the wild that contains this part of the API.

Of course, it’s fully present in the javax / javaee-web-api / 6.0 dependency which completely FAILS when used with EclipseLink JPA 2 implementation, which is why I moved away from it to begin with.

How can you expect anyone to get anything done in an environment like this?