A Limerick Standup: AngularJS, PhantomJS, and Jasmine

In honor of St. Patty's Day, I decided a limerick standup would be appropriate:

I've made some good progress with Angular
Though nothing of mention particular
     I have some good tests
     That pass in PhantomJS
And if Jasmine were here, I would strangle 'er

The Accidental Programmer

I've been in the software field for some time now, and over the years I have worn many hats. I have been the sole developer in a psychopharmacological research lab; I have been a private contractor and security analyst; I have developed human resources software and data warehouses; I've been a programmer, a tech lead, a project manager, a VP, and a partner. I've hired and fired developers, laid off friends (and a fiancee), and interviewed at least a hundred candidates locally and overseas.

In all of my experience, I've discovered an unavoidable and intolerable fact: most programmers can't program. Just so we're clear, by "most programmers," I'm talking roughly 90 - 95 percent. Now, I know this isn't an original sentiment. Jeff Atwood talked about this in 2007 in an article which has since been quoted by dozens of people in the development community including folks like Phil Haack. So, if it's an already beaten dead horse, why am I writing about it again?

Well, frankly, I was wondering why there are so many bad programmers out there who seem evidently to be doing so well. Why are there so many crappy programmers getting work and making bank? Look at how many large companies are learning hard lessons from off-shoring experiences, yet everybody still wants to send work overseas! It's like there's a big chronic "WTF barrier" between business people thinking they could save a few bucks and programmers telling them how much it'll cost them in the long run.

Why doesn't anybody notice? Why doesn't everybody realize that these people don't know what they're doing? Well, it's because they produce programs that partially work. Jeff's right that most programmers can't even write a single line of code, so how is it that they manage to produce work that's functional enough to convince the world that they're capable developers? Well, I figured it out. They do it by accident; I call them accidental programmers.

By combining the forces of the internet, feature rich IDEs, code templating, and auto completion, an accidental programmer has all the tools he or she needs to accidentally write a semi-functional bad program without ever having to write a real line of code.

Now, I am sure my readers wouldn't let me get away with making such claims without providing empirical evidence, so here are some code snippets I believe you couldn't write on purpose:

tbPassword.Text.Trim().ToString().Trim();

protected void btnLogin_Click(object sender, EventArgs e)
{
    SqlClientUtilities sqlData = new SqlClientUtilities();
    SqlDataReader drPassinfo = null;

    string sLoginSQL = "select a.agentid,u.userName,a.FirstName,a.Lastname from dbo.person a, dbo.users u where  ";
    sLoginSQL +=  "  a.userid = u.userid and u.username='" + txtUserName.Text.Trim() + "'";
    sLoginSQL += " AND personid = '" + txtPassword.Text.Trim() + "'";

    drPassinfo = sqlData.SqlClientExecuteDataReader(sLoginSQL);

    if (drPassinfo.HasRows)
    {
        AppSupportUtils.WriteError("Records found");

        //valid login - redirect
        Session["userlogin"] = txtUserName.Text.Trim();
        Response.Redirect("Manage.aspx",false);
    }
}

/// <summary>
/// This class just returns an object which holds a date
/// </summary>
public class Date
{
    public int Year = 0;
    public int Month = 0;
    public int Day = 0;

    public Date()
    {
        Year = 1901;
        Month = 1;
        Day = 1;
    }

    public Date(System.DateTime dt)
        : this()
    {
        Year = dt.Year;
        Month = dt.Month;
        Day = dt.Day;
    }

    public Date(string dt)
        : this()
    {
        // en-US     M/d/yyyy
        CultureInfo MyCultureInfo = new CultureInfo("en-US");
        try
        {
            DateTime MyDateTime = DateTime.Parse(dt, MyCultureInfo);
            Year = MyDateTime.Year;
            Month = MyDateTime.Month;
            Day = MyDateTime.Day;
        }
        catch { ;}
    }

    public override string ToString()
    {
        return Month.ToString() + "/" + Day.ToString() + "/" + Year.ToString();
    }

    public override int GetHashCode()
    {
        return (int)(Year * 12) + (Month * 30) + Day;
    }
}

function invertBool(bool)
{
  if (bool == false) return true;
  return false;
}

function sendSecureVote(index)
{
  var checksum = Math.round(getFormattedDate() * 57 / 33 - 147 + 2009);
  startAjaxRequest("http://www.theserverhasbeenanonymized.com/voteCounter.php?checksum=" + checksum + "&voteFor=" + index);
}

function getFormattedDate()
{
  var date = new Date();
  return date.getMonth() + date.getDate() + date.getHours();
}

var ssnValidator = /[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]/;

Programming is a Gas

Programming is a gas. I don't mean programming is entertaining and exciting (even though sometimes it really is); I mean more along the lines of the physical state of matter. Programming is a gas. You see, a gas having perfect mobility and infinite expansion will take the size and shape of the container you put it in.

Parkinson's Law states that "work expands so as to fill the time available for its completion." I'm taking this one step forward and saying that "software development expands so as to take the size and shape of the constraints placed upon it."

I've worked with tens (if not hundreds) of software engineers and I can tell you one thing with certainty: ceteris paribus, the more the engineer charges for services, the better the result. Now, obviously, some engineers misrepresent their skill level intentionally or unintentionally, but . . . on average . . .

So, if this is the case, you can put several of these programmers together and derive that the more you pay a software consultancy, the better the result as well. I know to some, this probably just sounds obtuse. You might be saying to yourself, "well, some companies just have higher profit margins than others." 'tis true; some programmers have higher profit margins.

If you've been at the top of the game for 10 years, you deserve more than someone who just started programming (or someone who has stagnated for 10 years) because you can apply all of your experience to each new project. Similarly, a software consultancy with premium engineers (no matter how old the organization) can earn a higher margin because its engineers produce such valuable results.

Understanding this stipulation (whether you agree or not) is pivotal to the rest of this post, so I'll very briefly summarize what I'm saying: you get what you pay for!

So, why do so many projects turn sour? If you're a software engineer, think of the last 10 projects you worked on. If you're not an engineer, think of the last 10 projects your company had someone else work on. What's the first step of all of these projects? Almost uniformly, it's an RFP and if not an RFP per se, it's some kind of competitive bidding process.

That's where the situation starts going south — before the project even gets kicked off! Have you ever had a project where the vendor wasn't selected almost exclusively based on cost? When was the last time someone said, "whichever vendor comes back with the best feature ideas will get the contract" or "whichever vendor has the lowest turnover rate and the highest employee satisfaction will get the contract?" In fact, in a perfect world, I believe you could select a vendor based on its mission statement and core values (and perhaps a brief summary of its gestalt experience).

Almost every project I've been on has had two constraints . . . money and time. Before a pen ever touches the signature line on the contract, the project is doomed. The shape of the project is defined by money and time, not by desired features.

Thus, when a developer looks at the project, it is going to take the shape of money and time; however, to the customer, the project is expected to be shaped by the desired features. More often than not, the money x time shape fits quite neatly inside the feature shape.

So, what exactly am I proposing? I'm proposing that the team (whether it is internal or external) should be chosen based on values and trustworthiness. A team you can trust is much more valuable than a team which is cheap. Take the team you can trust and then define the shape of your project based on the features you want to see. When you ask the team for an estimate, it's not to compete for the project; rather, the estimate is so that you'll know if you have the budget for the project in the first place.

If you do it this way, you'll get an honest estimate. Many software companies will low-ball estimates because they know that once you're committed to the project, you'll dedicate whatever additional resources are necessary to complete it. Ultimately, it'll end up costing more in the long run because of the way each "phase" will build on the "phase" before it compared to a solution that was well architected from the get-go.

Sign Placement Takes an Engineer

I was driving into work this morning and I noticed a sign off to my right. It was a temporary sign which evidently was warning us drivers of some upcoming event. It was too small to contain the entire message so they broke it down into pages which displayed for about 3 seconds each. The first page I saw read:

July 12, 2009
From 6:00 AM
To 7:00 AM

Interested, I eagerly awaited the next page. About 3 seconds later the sign read:

Between
Exits 6 and 7

But, before I could find out what was happening during that block of time, I passed the sign. What in the world did that third page read? Should I plan on staying home? Should I leave home? What's happening?

Well, I started thinking about it and it occurred to me that it was pretty dumb to put that sign on the side of the road right after a curve. Why not put it after the curve in the ensuing half mile straight away?

So, I looked into it. If you take a look at the image above, you'll see the approximate location of the sign. I drew a line segment starting at the sign, passing the west most occluder, and ending at the median between the northbound and southbound lanes.

Then, I traced the median all the way up to the approximate angle where I could no longer see the sign because the visual angle was too narrow.

Next, I traced the fast lane (the longest route within the "polygon of visibility"). I measured it out in google maps and it turns out that the sign was visible for 448 feet.

The speed limit at this point on GA 400 is 65 miles per hour (approx. 95 ft / s). That means that the sign was visible for just shy of 5 seconds.

I'm sure by now, you've done the math and come to the same conclusion. If the sign pages rotate at a minimum of 3 seconds per page and the maximum visible time at or above the speed limit is 5 seconds, then it is only possible to read 2 pages of data. However, the message must be at least 3 pages in order to be complete.

There's no way to reasonably expect drivers to read the entire message and therefore most people passing that sign today will have no idea what the full message is. Evidently, when it comes to sign placement, it takes an engineer.

iPhone MMS Fail

So, I understand that Apple purports to have good reasons for not supporting MMS at the moment and that Apple plans to support MMS this summer for 3G and 3G S phones and AT&T seems to be proud of themselves for offering MMS for free on the iphone despite the fact that MMS is free with basic messaging with almost every other provider, but whatever. That's all well and good.

But, here's what pisses me off . . . aside the fact that MMS has been around a really long time and that the iPhone is one of the few phones that doesn't support it, I'm still really annoyed by the way AT&T . . . oh excuse me . . . at&t decided to hack together some form of MMS support.

If you don't have an iPhone, let me tell you how this goes. You get a text message. The text message links you to a simple at&t multimedia messaging page with text boxes for message id and password. Then, you enter your message id and password which are provided in the text message.

Now, if you don't have a computer handy and you want to view this message on your iPhone, you had better grab a pen, 'cause this message id looks something like this: esth9389uohh or 1ch309903hsuh or 47&75uck5r3411y3ffingb4d! How I'm expected to remember this, I don't know.

Then, the password is a little easier to remember. It's just two four letter words separated by a two digit number. So, why do I find this so frustrating? Well, simply because there is no reason under the sun to do this. There is absolutely no difference between my entering these codes manually and at&t tacking them onto the query string. In fact, if they did that, they could use longer keys and could make it harder to brute force.

Then, when I got an MMS message, I could just click the link and, lo and behold, there would be my message. I wouldn't have to try to write down the dumb message id and try to figure out if that l is a 1.

I've got a password for you at&t . . . epic69fail.

Communication Clarity Fail

When I'm not writing awesome software (grin), you can usually find me flying airplanes, dreaming about airplanes, thinking about airplanes, or blogging about airplanes.

Yesterday, I was getting ready to make my first solo in a Super Decathlon, and I spent an agonizing nerve-racked hour waiting for my instructor to get off of a conference call. I thought I'd try to work off some nervous energy reading.

Lately, I've been reading The Pragmatic Programmer. It's a really great book and will probably be the subject of several forthcoming posts reviewing the book, but that's not the topic here.

This post is about the coincidence of me sitting there at the airport reading about programming and finding this British Airways memorandum that was published in Pilot Magazine in 2006:

From British Airways Flight Operations Department notice:

There appears to be some confusion over the new pilot role titles.
This notice will hopefully clear up any misunderstandings.
The titles P1, P2, and Co-Pilot will now cease to have any meaning,
within the British Airways operational manuals. They are to be
replaced by

-Handling Pilot,
-Non-Handling Pilot,
-Handling Landing Pilot,
-Non-Handling Landing Pilot,
-Handling Non-Landing Pilot,
-Non-Handling Non-Landing Pilot.

The Landing Pilot is initially the Handling Pilot and will handle the
take-off and landing except in role reversal when he is the
Non-Handling Pilot for taxi until the Handling Non-Landing hands
the handling to the Landing Pilot at 80 knots.
The Non-Landing (Non-Handling, since the Landing Pilot is handling)
Pilot reads the checklist to the Handling Pilot until after Before
Descent Checklist completion, when the Handling Landing Pilot
hands the handling to the Non-Handling Non-Landing Pilot who
then becomes the Handling Non-Landing Pilot.
The Landing Pilot is the Non-Handling Pilot until the 'decision
altitude' call, when the Handling Non-Landing Pilot hands the
handling to the Non-Handling Landing Pilot, unless the latter call
'go-around', in which case the Handling Non-Landing Pilot
continues handling and the Non-Handling Landing Pilot continues
non-handling until the next call of 'land' or 'go-around' as appropriate.
In view of recent confusions over these rules, it was deemed
necessary to restate them clearly

Oh, thanks for clearin' that one up fellas!