Tag Archives: software

Today’s Challenge: Build a better system during the training meeting

2 Replies

Had a mandatory training meeting today on our time tracking software. Since we already had to figure out the 33 step process a few weeks ago so we could get paid…  today we had an impromptu hackathon.

This software is so bad that surely I can build something better during the training meeting for said software.  -Me

Now, how to beat my coworker Mikkel who is wicked good? We both have to vaguely pay attention to the webinar so that’s an equal handicap. Aha, don’t acknowledge that I’m serious until about 15 minutes in. Especially since my computer is creakily working toward four years of service so a few tasks that should take 20 seconds instead drag on for several minutes. It’s about five minutes into the hour when I start, in theory that leaves 55 minutes to build something cool.

Ok, grails create-app timetrack.
Create a user domain class to sub in for a real authentication plugin.

Now the biggest problem with the real time-tracking software is that you have to enter hours for each day.  This is dumb when the only useful purpose it serves is to track vacation time and try to avoid everyone being on vacation at once during a big release.

Don’t want an hours worked for the day object, let’s do the opposite and create-domain-class TimeOff.  Next create some controllers, set scaffold=true and voila we’ve the world’s simplest app for entering time off.

One of those commands takes much longer than it should and after firing up Intellij as well I’m at the 15 minute mark.  Mikkel realizes I’m serious and starts cranking out a rails app. 

No problem, time for a secret weapon: Dojo.

I know Dojo has some great calendar widgets and a calendar sounds like a good interface for something concerned with days and time. Start looking through docs; not that calendar; this looks right; nope wasn’t that either.  Ok, finally got the right code, still getting a weird error though…

And the webinar is over, done after 40 minutes.

What?  I’ve only been coding for 35 mins and Mikkel for 20.  Well, time to show our results.  Mikkel’s lets you enter hours worked one day after another.  With about 15 steps to fill out a two week pay period it’s a more than 100% improvement over the same part of the real app.  And mine?  Giant javascript error, typical dojo.  Damn.

Couldn’t let it end there though.  Put another 15 minutes in to wire up json output in Grails and get the javascript error fixed and…  Bam, a decent prototype for the interface.

timetrack

For comparison, here’s the real app.  Now I just need to turn my prototype into a real app…

Submit Time Sheet Express Page

How to strangle productivity

Leave a reply

Step 1 Outlook Web App.  Step 2 Time Tracking software.

I’m not quite sure why companies adopt time tracking software.  A friend mentioned that he thought there was some accounting treatment that encouraged it but some web searching has only lead me to BS statements like these.

“Time is money, so once it is clear where employees are spending their time, an employer can decide how to better prepare and deal with projects.”

“With a distributed company it ensures that everyone is working.”

Yes, entering eights into boxes ensures that I’m working.  Apparently if the time tracking interface is as cumbersome as possible someone can be extra sure that I’m hard at work.

Now, HR people tend to be extremely nice and well-meaning, perhaps this makes them especially susceptible to the sales pitch of time tracking companies. I understand if a company has part-time employees, or is billing hours to clients; then tracking those hours can make sense. For salaried employees who are otherwise being treated as adults, it’s a gigantic waste of time. Particularly if the software requires a training meeting.

Which leads to TODAY’S CHALLENGE.

Upgrading to Dojo 1.7.2

1 Reply

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

1 Reply

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…

Managing Software Projects

2 Replies

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.