While I Compile

… I compile my thoughts about programming

My reaction to being named as a Canadian programmer worth following on Twitter

Yesterday John Bristowe published a list of Developers in Canada You Should Follow on Twitter.

I was humbled and honoured to make the list. … actually, I was a little more excited than that, here’s a dramatization ….

… Thanks John … I’ve been dying to use this video in a blog post. 😉

Advertisements

October 4, 2010 Posted by | Non-Programming | 4 Comments

Thoughts grow to tweets, then blogs, then they just die

I’ll often want to Tweet something, but feel the need to explain further in a second Tweet. But something in that will need explaining, so it occurs to me that I really need a blog post. But then I realize I should probably post this as 2 or more separate posts to isolate ideas and keep them self contained and just link between them.

Then I realize I’ve got work to do, and drop it till I have time …
… which never comes and my thought dies having never lived.

*Even this one tweet expanded into a blog post!

November 14, 2009 Posted by | Non-Programming | , | Leave a comment

… so I can worry about curly braces

I just wanted to take this Remembrance Day opportunity to thank all the Canadian soldiers, past & present, living & dead, along with those of our allies, for your dedication & sacrifice.

Thank you for fighting for our liberties so we can worry about the more important things like; litterbugs, dynamic vs. static programming languages, and the endless irrelevant debates about curly braces.

Canadian National War Memorial - Tomb of the Unknown Soldier

Canadian National War Memorial - Tomb of the Unknown Soldier


This image taken by Andrew Moor

November 11, 2009 Posted by | Non-Programming | | 1 Comment

2 Rules for a Happy Client while Billing Hourly

Some of my projects are a fixed rate and some are hourly. If the scope of the project is small enough to accurately estimate, risks are minimal, and nailing down requirements is practical, I may propose a fixed price. Working on fixed price projects are a piece of cake, I go home, work on it, provide periodic updates via email, phone, or in person. When I finish it I install it and give them a CD with all the binaries, documentation, and source code.

However, I’ve found working on an hourly rate to be a little different than doing all the above while just counting my hours. There is a lot of distrust with hourly professionals which is only compounded with a mysterious process like software development. After all how do they know you aren’t home watching soap operas, working on your own projects, the project of another client, or even sitting on the beach? How can they tell they aren’t being over charged? The problem with trust, is even if you are honest, a false perception can still destroy the relationship.

I know this too well. Once in the late 1990s I was working from home, charging hourly, and I got a call from one of the newer partners of my biggest client (only client at that point). While talking I rebooted to clean out my system* and when the system came back up it played the 20th Century Fox theme, a configuration change I thought was very cool, and he said ‘Are you watching TV?’ I said ‘No. Why?’ … Seriously, I didn’t even making the connection. Two days later I was called in for an unscheduled meeting where my invoices were questioned, I heard a lot of “we’re not accusing your of inflating your hours…”, and the next day, feeling insulted and unappreciated, I resigned. I didn’t make the obvious connection until much later. It doesn’t matter that I was under charging both in terms of my rate and what I charged for, and would never inflate my hours! It doesn’t matter, because the perception was corrupted. It was a tragic misunderstanding since I loved working there and provided a competent, yet naively discounted service.

That’s when I came up with rule # 1
1. Work at the client site when charging hourly.

While following this rule gave my clients assurance that I was actually working, it still left them in the dark as to my effectiveness and what exactly I was doing. I soon realized that working on site isn’t enough. I need to communicate my challenges and accomplishments more effectively as well.

So I came up with rule # 2
2. Provide detailed invoices.

Until this point, my invoices had the typical, single ‘All services rendered’ line item. I changed it to include every single thing I did. I’m not kidding. Here is a sample from an invoice I wrote a couple years ago, after establishing this rule:


App F – Investigate & Fix bad XXXXX data

App A – Altered data tables to use the datetime data type for the create_dt & update_dt fields. This is needed to have a granular time for list updates. Communication /w Coder X and answering his questions. Conversation with Coder X about Stored Procedures. Discussions with Coder X about the stored procedures. Generating Business objects.

Feature X – Add Save & Save to Profile to the IFeatureX specification. Alter the Feature X specification document to include autosuggest searching ability in the IFeatureX interface. Reviewed Coder Xs progress.

Planning – Discussions with Manger Y about the purchase of App R, project status, and got permission to take the API documentation for App R off-site for review.

Website – Added new user.


Notice how it’s written for the target audience (a non-programmer, IT manager in this instance)? Notice all the detail? Notice I explained why I was changing the data types? Notice the descriptive verbiage (investigated, fixed, altered, reviewed, etc…)? Notice how even something as basic as adding a new user to the website, a 5 minute task is included? Notice I confirmed my permission to take confidential documentation off premises?

There is some terminology which might be unfamiliar to my client, but these terms were introduced to the client before hand, so they understood every thing said on that invoice when it showed up in their inbox.

All this detail may seem like overkill, but it gives the client a level of transparency into the mystical world of software development. It provides a record of activities, allowing the client to feel in control, knowing the priority decisions they made are being acted upon as agreed. It reveals a shadow of tangible evidence on an outwardly invisible service. But most of all, it gives the client comfort and I believe raises the level of trust.

I should also point out, the invoice sample above is not based on a 50-60hr work week, but from a week where I put in 14 billable hours. A 50-60hr work week would usually be 500 words or more.

… hey! Don’t freak out, you can write a detailed invoice without spending your weekend on the first draft. Here’s a brief list of things you can do to reduce the time you spend writing monster invoices:

  1. Maintain a detailed time log filled out as you do things. This takes discipline, but almost no time.
  2. Make detailed source control comments and do a report at the end of the time period.
  3. Make detailed bug tracker notes and list all the bugs/tasks/tickets you worked on during the time period. You can just list the bug ids, but I usually write something like ‘Investigated and resolved ticket # N – User receives 404 error when clicking customer link’.

The key to any of these is to write with your client as your intended audience, this way you just cut and paste into your invoice.

More than a decade after reluctantly getting into consulting, I’ve realized that Perceived value is directly related to the quantity and quality of communication with the client. An invoice can be a key communication device with your client and a powerful marketing tool if you make the effort.

*It was Windows 95 after all. At that point I was rebooting 10 times a day at least.

Copyright © John MacIntyre 2009, All rights reserved
WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

July 9, 2009 Posted by | Consulting, Non-Programming | , | 1 Comment

AboutMe.xml

I have a pet peeve and like most pet peeves it’s an irrelevant petty little annoyance, not quite a huge, humanity, oppressing problem.

My pet peeve is filling out the same information; name, address, city, etc… on paper forms. All that standard information at every doctor’s office, school, activity registration form for my kids, etc… I mean why do I need to keep writing this stuff? And why does somebody else have to take the time to retype it into their system?

Really! In all seriousness … what a waste of time! 5 minutes I’ll never get back, every time I start a new relationship with any organization.

But wait … I have a vision! Not a big glorious, save humanity vision, it’s more of a save each person 5 minutes of writers cramp, kind of vision. Yes! That kind of glorious vision!

I was originally inspired with this in the mid 1990’s. It started out as a question; why can’t doctor’s receptionist retrieve this information from the province when they scan my health card. But since the likelihood of getting the government to add an API for this is slim, it was reduced to something simpler. Like; Why can’t I hand the receptionist at my new doctor a diskette with an ‘aboutme.txt’ file on it, where she can load it into her PC, and give me my diskette back? This would free me up to spend an extra 3-5 minutes browsing the 4 year old magazines during my 76 minute wait to see the doctor.

Over the years, this vision has transformed from an aboutme.txt file on a 3.5” diskette to an aboutme.ini file on a diskette to an aboutme.ini file on a website to an aboutme.html file on website to an aboutme.xml file on a website to an aboutme.xml file on a USB memory stick. I’m not even going to go into ideas I had for RFID, bar coding, or carrying around printed labels in my wallet.

I’ll agree; this isn’t a big problem, but it’s an irritating little annoyance which can be easily overcome with a very simple programming solution. Surely, this would become a reality. Surely, this simple idea would be recognized by others, and implemented.

But alas, the obvious was never realized and because it would be impractical for any organization to expect you to have this aboutme.* file in your back pocket when nobody else had one or was asking for it. It’s the typical chicken / egg scenario; you need one to start the other.

But now I’m inspired again … by Open ID, or possibly another similar centralized authentication mechanism.

When I log into a new site via MyOpenID, I can chose the persona I want revealed to the site I’m logging into for the first time. One of these personas could easily contain standard address information like that required in the types of situations listed previously.

As Open ID reaches critical mass, with more people understanding and adopting it, providing and/or recommending software functionality to accept basic information via an Open ID login will become more realistic.

It’s easy enough to imagine a plausible working process, so I won’t bore you with that. However, there would be serious security concerns regarding logging into a critical authentication mechanism like Open ID from a shared kiosk, so the user would want to log in via their personal cell phone (or laptop or PC or …). And mainstream user adoption has a long way to go before something like this would even be offered, not because of technology, but due to slowly shifting paradigms.

There are obstacles to overcome before this could ever become a reality, but with centralized authentication schemes like Open ID, expecting most people to have an electronic copy of their basic information available will eventually be reasonable, and generic business software applications will start consuming that information.

And one day, hopefully before I die, I won’t have to fill out another one of those stupid forms.

Copyright © John MacIntyre 2009, All rights reserved

WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

May 11, 2009 Posted by | Non-Programming | , , | 3 Comments

Twitter users need a Valet Key for 3rd Party Tools

I’m noticing a lot of Twitter tools requiring the user to enter their Twitter user id and password to use the tool. These tools obviously need the users’ credentials to access the Twitter API and act on behalf of the user.

But am I the only one who is uncomfortable with this? I mean, isn’t the first rule of passwords not to give them out to anybody? Isn’t it?!?!?

Instead it’s become the acceptable practice to enter it into every app requesting it! Correct me if I’m wrong, but as far as I know, you can’t use TweetDeck, StockTwits, or Twubble without entering your Twitter credentials, just to name a few.

Now you may say, the risk is low … I mean who really gives a hoot if my Twitter account gets hijacked? I’ve currently got 91 followers, many of which are social media experts looking for reciprocity follows anyway! Who cares? Nobody’s listening! Maybe so, but all it really takes is one follower who trusts me to go to a phishing site and act on ‘my’ recommendation. The risk is high enough for me.

The stakes are even higher for users with larger followings. Do you think Ashton Kutcher, with his 933k followers, doesn’t use any of these tools? Do you really think he’s using the basic web page? I doubt it.

…. maybe I’m being paranoid. After all, I have zero qualms about entering my sys admin credentials into my database tools. Currently I use Microsoft tools to access my SQLServer databases, so there is a bit more trust, but I still wouldn’t have a problem entering my credentials into TOAD to access an Oracle database.

My fear is that as more web applications attempt to expose their API’s to 3rd party developers, this unsafe credential divulging scenario will only proliferate.

What is really needed is second tier Twitter access. Like the valet key for your car, you can hand over the keys to the valet, but they can’t pop the hood, get in your glove box, or steal the golf clubs out of your trunk.

It’s late and to be honest I don’t immediately see any good way to handle this, but here are some initial ideas:

  1. A second lower tier password specifically for 3rd party tools
  2. Having the tool redirect to some kind of Twitter log in page, hosted on Twitter, which would then return the user to the tool web site, while providing access in the name of the user.
  3. The ability to log into Twitter and get a temporary or permanent ‘application key’, which the user could copy & paste into the tool.

Option 1 and 3 both kind of suck, with 3 adding any extra cumbersome step, increasing resistance and dropping adoption of these tools.

The interesting thing is that option 2 already exists! Twitter already has a valet key called ‘OAuth’, there’s even a FAQ and sample code to help developers incorporate it into their software.

WeFollow is currently using it. If you go to their home page (do people still say home page?), click on the ‘Add yourself to WeFollow’ image, you eventually get sent to a Twitter authentication page. Once you authenticate yourself, and you get sent back to the WeFollow site. This is nothing new, and is used in PayPal and MyOpenID just to name two. Later, you can go into your Twitter Settings, select the Connections tab, and remove WeFollow from having access if you want to.

This doesn’t really work well with a desktop application, since the browser would probably end up being embedded right into the desktop app anyway, which doesn’t really have the detached neutrality feel of a 3rd party web browser does it? So some type of valet key for the desktop apps would still be preferred, but in truth, I feel a lot more comfortable entering my credentials into a desktop app, than an unknown website any day.

The real question is; why aren’t all the other web apps using OAuth? Why does StockTwits require their users to enter Twitter credentials into the StockTwits website instead of using OAuth?

Why aren’t their users demanding it?

EDIT:Brent Ozar has indicated that OAuth is fairly new and many sites just haven’t finished factoring it into their user model yet. Thanks Brent.

Copyright © John MacIntyre 2009, All rights reserved

WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

April 16, 2009 Posted by | Non-Programming | , , , | 3 Comments

Finding my voice

I’ve written before (non-programming) and although I’m not a writer, I feel I wrote fairly well. I mean it was time consuming, and I probably made grammar errors which I’m not even aware of … but all in all; I feel I did a good job.

However, since starting ‘While I Compile’, I must admit, I haven’t felt the same kind of flow. Each post has been forced, and in rereading them, I’m unsatisfied. For example, the post on ‘Knowledge Holes & The Brilliant New Programmer’ describes an insight, which colleagues and clients thought was perceptive when told verbally, but when I reread that post, it doesn’t seem to pack the same punch.

I do enjoy blogging, and plan to continue. I’ve got a ton of great ideas and thoughts I want to share. But basically, I appear to be in the ‘Finding Your Voice’ phase. Over the next couple months, I may try a few different styles, and see which one is the most effective. By effective I mean; first and foremost delivering real value, maximizing my efficiency, and maximize my own insights, innovations, and learning.

I hope you’ll stick with me during this phase, don’t judge this blog based any one post and possibly even subscribe to the feed. Like I said, I do have some really good ideas that I plan to share.

Please leave a comment below on anything you feel I’m doing right, or anything you feel I could improve.

Thanks,
John MacIntyre

EDIT [02/24/09] – I’ve since yanked the ‘Knowledge Holes’ post. I’m just going to sit on it for a while, and perhaps it will be reborn in a new post in the future.

February 20, 2009 Posted by | Non-Programming, This Blog | Leave a comment

Purpose of ‘While I Compile’

The purpose of this blog is to express my ideas about programming, software architecture, business of software, technical consulting, database design, etc…  I will also share code from my prototypes and proof of concepts.

I’ve wanted to share my thoughts and ideas about software for a long time, but was put off by two things; a) I wasn’t sure my ideas were that good, and b) I was nervous about exposing the holes in my knowledge via my ‘self declared’ insights.

As time goes on, I meet more and more programmers; and I have come to realize that my ideas do add value.  Although there is much I still don’t know there are many who will benefit from what I have to share. I have also changed my position about exposing the holes in my knowledge; and now see it as an opportunity to find and fill those holes.  Just writing about my thoughts will force me to be more aware to the implications of different decisions, and the limits of my knowledge.

I welcome criticism and disagreements put forth in a constructive manner.  And look forward to working with the commenter to find the truth and/or distinction so each of us can move forward a little better off.

Thank you for your time, and I look forward to sharing my ideas.

Copyright © John MacIntyre 2009, All rights reserved

WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

January 28, 2009 Posted by | This Blog | Leave a comment

   

%d bloggers like this: