Upgrading to Dojo 1.7.2

Upgrading a project to dojo 1.7.2 from 1.6.0.  While I could simply point to the new version (it seems quite backward compatible), I think it’s time to switch to the new AMD compatible require / declare syntax.

Step 1.  Pointed at the CDN and set async to true:

<script type="text/<span class=">// <![CDATA[
// <![<span class="hiddenSpellError" pre="">CDATA</span>[
// ]]></script>
javascript" src="//ajax.googleapis.com/ajax/libs/dojo/1.7.2/dojo/dojo.js"
// ]]></script>
 data-dojo-config="async: true, parseOnLoad:true">
</script>

Immediately the async: true caused dojo is undefined errors from dojo.byId and dojo.require statements.

// A slide out tab
dojo.require("dojo.fx");
dojo.addOnLoad(function() {
    dojo.animateProperty({
        node:"slideOutBox",
        properties: {
            height: 0
        }
    }).play();
});

The fix was pretty easy

Step 2. Change dojo.require to require and move dojo.addOnLoad into

require([“dojo”,”dojo/fx”, “dojo/domReady!”], function(fx){
});

 

Upgrading custom dojo build to 1.7.2

First build overwrote dojo.js, oops, which gave this unhelpful error,

js: uncaught JavaScript runtime exception: ReferenceError: "require" is not defined.

Note: I should have finished this post a year ago when I was doing the upgrade.  There were a few more issues I ran into but it’s a bit fuzzy now.

Project Failure

Part 1 of Managing Software Projects

Your project sucks.

It’s months late, over budget, full of bugs, or maybe it’s a total bust.  Worse, if you are managing the project you don’t even know how bad it is because you can’t spend your time crawling through the depths of the code.

At least you’re in good company. 70% of software projects fail to meet their budgets and deadlines and 1/4 of projects fail completely.

If failure is common, what can we learn?

First, let’s take off those rose-colored glasses that we put on every time we work on our résumé and look through our past jobs. “How many of your software projects have failed?”  It’s likely that not many come to mind, certainly not 70%. Most software operations tend to forget their failures or they never really kill off projects,

letting them sit around in a zombie state sucking morale from employees’ brains. Or, large projects are often partial failures once you measure the amount of maintenance required to run them;  a drag on the company rather than an engine of growth.

It may also be complicated, “These apps work, these features don’t, I don’t even know if that part works or not.” Especially for the project you are working on right now, it’s useful to think about whether different modules or features are successful or not. After all, the goal is to apply some bolt cutters to the parts that are a weight chained to your ankle and let the other parts of your project soar.

So it’s not enough to ask, “How many of your software projects have failed?”.  We’ll also ask “How did these projects fail?” Failure can take a lot of forms and it’s hard to measure something that people struggle to quantify and struggle to get good data on.

The largest source of failure, product failure, involves a lot more than software management. Getting the right product to customers for the right price, selling them on it, that’s the goal of most businesses and that’s the elephant’s graveyard of failures. Again, features or modules are often in this category. A set of features are developed for customers at great expense and then never rolled out or never purchased. Good prioritization can help with this problem, it’s a good compass, but when your customers are on the other side of the river a compass is not much use.

However, for now we’re concerned with software project failure—things that cause software projects for a good product to go awry, to fail completely, or to fail partially. First there are projects that got canceled. Those are clearly failures, right? Something was started, got some way along—a month, six months, two years, ten years—and then someone finally realizes that it’s a disaster and the company needs to stop working on it. Often this is because it’s gone way over budget or way over deadline. As the small problems add up over months or years, it’s easier to see, “Oh, this has gone really wrong.” “We were supposed to complete this in a year, it’s been two years, and it’s still not done.” Particularly this happens on projects for the government where there’s a set initial budget, things go late, extra funds are procured, but eventually things go so bad that the whole project ends up getting canceled.

Other projects get built and never rolled out, canceled in effect by the users. There isn’t enough checking in as the project’s being built, so when “suddenly” it’s time to deliver the project people realize, ‘Hey, this doesn’t do what we need,’ or ‘It does most of what we need but this last 10% is so critical that we’re going to ditch the whole thing; we can’t make the transition to that new software.’  All of these are failures due to lack of communication with users.

Another case is the cobbled-together software in use by customers that everyone agrees desperately needs to be redone. Similarly you often find software where the maintenance costs are too high, it’s not extensible enough, it’s breaking too often, it’s pretty clear  that new software needs to be built. A new software project is launched. Version 1 was at least a partial failure, thus we have Version 2: the complete rewrite.  Or 3.  Version 4: the complete rewrite? I think I saw that one already, it was much better with that one actor, you know, the guy with the long hair and the Linux Rules T-shirt?

When you add up these different kinds of software project failures you get that headline failure rate of 70%. People have studied this for decades and many studies come to the same conclusion.

Why is software hard?  Next up Software Engineering…

Partial test coverage

Software, it’s a mean scary world full of monsters just waiting to get you.

By which I mean everything is nice and cozy when coding away on a cool new feature within the four walls of your company. But there is a whole world of bugs and performance problems and security holes and confused users out there just waiting to pounce.  Just let that code into the wild they whisper.  Give it a basket of goodies and a red hood and send it out the door.

Which is why we write tests.

Tests are windows that let us see the monsters lurking outside.  That monster has a big mob of users, better not let this feature out the door until it can run extra fast.  Those hackers like our basket of goodies, lets give this feature some more layers of protection … and a flamethrower.

One of the projects I work on has about 10% test coverage.  When tests break or need upgrading someone (clearly of the non-test writing persuasion) will ask, “why should we spend time adapting the tests to the new code?”

Because, it may just be one window, I can only see part of the back yard but at least I can see a few things.  Sure, you can always go out the door and look around; maybe there’s nothing out there. With at least one window, if anything really big is lurking about, you’re sure to see part of it.

Is that a tail?

Anti-Pivots or Company Focus

Focus is a difficult thing as a start-up.  By definition you’re exploring a space: trying to find what you can build quickly that enough people will pay enough for. So you’re jumping around all the time.  We’ll do A which will lead to B which will…  No too long or too expensive, instead we’ll do C which requires an agreement with D.

For me it was who is the best customer for the value created in StickyVote.  State legislators; no, federal legislators; no, newspapers; big advocacy organizations; small ones.  Maybe users through this new Facebook thing?

The problem is that these shifts, while important, can confuse and wear down staff and pilot customers. Since focus and enthusiasm is going to shift, what would I do different next time?

Set more criteria for judging whether something is successful.  How can we prove whether this is the next right step?  Or what would demonstrate that this is the wrong early adopter?  It’s easy for some time to go by, attention to shift and to say, “This isn’t working.”  Which is an easy excuse to switch to whatever is exciting and new that week.

Ok, money isn’t pouring in; there are a million theories for why not. Before getting too far into those, lets look at why we thought it would work.  Have we put the new idea/software/pitch in front of enough of the target customers?  Is it just one first impression that we’re operating off of or is it really enough opinions to mean something.

Good things come from setting criteria. First, if I don’t have some initial criteria for measuring a new direction, then I shouldn’t talk to my staff about potentially shifting course. Second, refining the criteria with staff means they can hold me accountable when I next want to shift.  Just as a good agile process adds transparency to development and priorities, a good “direction process” should do the same for big questions.  Where are we going? Why? How do we know if this is a step on the right path?

Gigabyte P55-USB3 motherboard with 2000 MHz RAM

Just plugged 8GB of G.Skill 2133 mhz ram into my desktop.  The memory clock speed stayed at 1333 mhz when I did so which led to some fiddling with bios settings.

I have a Gigabyte P55-USB3 motherboard with an i5 2.8 Ghz processor and plugged in 2 x 4GB modules of the F3-17000CL11D Ripjaws ram from G.Skill (in a nice red color to boot).  Motherboard manual is here, http://www.gigabyte.com/products/product-page.aspx?pid=3440#manual

Once in the bios config in the ‘MB Intelligent Tweaker’, the ‘Advanced Memory Settings’ seemed to have what I needed, ‘Extreme Memory Profiles’ for different speeds.   Profile 2 put the speed at 2130 mhz and all the advanced timing settings matched the memory specs (11-11-11-30 2N).  Unfortunately, it wouldn’t boot.  Switching between the different  profiles (disabled, profile 1, profile 2) and ‘Performance Enhance’ modes (standard, turbo, extreme) didn’t help much, the only way  I could boot was at 1600 Mhz in the disabled profile with extreme performance enhance.

Fortunately I hit on a nice overclocking guide, http://www.overclockers.com/3-step-guide-overclock-core-i3-i5-i7/

Leaving the memory settings at the default values, I  went into the ‘Advanced Frequency Settings’ section and changed the Base Clock BCLK to 200Mz with  the CPU Clock Ratio at 16x.  This gave me an overclocked CPU speed of 3.2 Ghz (seemed reasonable and a nice bonus) and put the Memory Frequency at 2000 MHZ (good enough).

After a few hours of serious programming work, the system has been completely stable and seems a bit faster.  Hope that helps.

Running your Government

In the absence of InnoVoter / StickyVote, you may be wondering, “how can I best manage my Government?”  I’m happy to report that this area is still a hotbed of startup activity.  Although several contemporary projects have shut down, some have morphed and new ones have started.

One of the new, Votizen.com, raised $1.5 million just over a year ago and has quite the who’s who of advisers and investors.  Interestingly they have chosen to focus on voter registration records; one of the big early decisions I made was just to prototype that piece and to leave full implementation for later.  Before too long we should see whether that will form a strong foundation for Votizen to build on or a crushing weight of software and data maintenance.

Next on the list is PopVox.com, co-founded by the guy behind govtrack.us, which is still a great source of Federal legislative data.  To communicate with Congress this is the best tool I’ve seen, they have great widgets and do a good job of grouping similar bills together.  The one other I recommend is OpenCongress.org, a non-profit with a strong community of users commenting on bills as well as any easy place to find general information on Congress.

Closing Down – Thanks

Long ago in 2007, I started a company.  It was more of a wild idea than most as it was going to not only make myself and many others rich but also change how politics work in America. Simple mom n’ pop sort of business.  Along with a few other crazy folks and with lots of help we launched stickyvote.com and part-time for two years tried to figure out how it should all work. Politicians, citizens, interest groups; making money, raising money; building software.  It was a fairly good idea but I didn’t figure it all out.

Now that it’s been a few years it’s time to write down the lessons learned that were the main yield of the company.  Perhaps they’ll save someone else some heartburn, and most importantly keep me from making the same mistakes next time.

But first, thanks to everyone who helped.  Thank you for your support, whether that was business advice, political advice, coming to early hacking sessions, being interviewed, donating through paypal or using the alpha product.  Thanks especially to those who put in cold hard cash and to the awesome employees and contractors who sweated away on the product.

Where are these rock stars now you may ask?
Georgia Lindsay, VP, her forthcoming PhD will change the way we relate to buildings.
Jeff Hull, Biz Dev, tells power plants how to run their software.
Luke Hamilton,  programmer, writes powerful Android apps (don’t push that button).
And Parwaiz Yahya, early investor, is taking over the retail world with me at skuloop.com

Thanks most of all to my wonderful wife Erica for all the encouragement and putting up with all the craziness.  Especially the next project…

SOTU 2012

After putting the kid to bed I caught the latter part of the State of the Union.  Good combative speech, I generally liked it.  I would have enjoyed more humility in the mention of our partnerships with other countries, we’re not actually in charge of the world it turns out.  But I do enjoy a feisty speech.

And the Republican response?  I liked the theme, a loyal opposition is critical and Mitch Daniels started off well.  However, “As a loyal opposition, who put patriotism and national success ahead of party or ideology or any self-interest.”  Oh, is that what threatening default on the debt was, causing economic uncertainty for months, the national interest?  Sorry Mitch, had to laugh you off the stage at that point.

Managing Software Projects

With software “eating the world” more and more people find themselves managing software projects.  While many people have experience programming and others have experience managing teams, software engineering has its own set of challenges.  Creating software that solves a problem, is easy to use, doesn’t break all the time, doesn’t die under load, is easily changed and adapted, that new programmers can learn quickly and for a reasonable price… is hard.  In this blog series I’ll cover the forces that drive software and what you can do to keep your project in the fast lane instead of  broken down on the side of the road.

The general outline.