The Getting Things Done Trap

In the world of software development there is an interesting bi-polar fascination with the “GTD” (Getting Things Done) mantra.

On the outside, GTD seems awesome and exactly what you want to strive for and a quality you want to look for in a team member.

However there is a dark side to GTD and that’s going to be the subject of this post.

There’s a classic quote I first heard from my grade 8 math teacher.

“No one ever plans to fail, they fail to plan.”

This statement is so simple yet so prolific. It is entirely accurate 99% of the time.

Let’s break down the things that can go wrong and cause a project to fail.

1.) There isn’t enough time to complete the project (even if you were Superman)
2.) The requirements are never solidified until a point at which #1 kicks in
3.) A technical challenge crops up that can’t be solved within time/budget (you find out you need to support infrared communication on a mobile device that has no IR sensors) and #1 kicks in
4.) Pure incompetence by 1 or more of your team members
5.) An external event beyond your companies control de-rails the project (e.g. A flood wipes out your building and electrical for 6 weeks and #1 kicks in

Everything except for #5 is something that could have been resolved if it was discovered and raised in time.

This is where the quote comes into play. If you plan out all the important aspects of your project, and maintain up to date digital documentation that everyone on the team can reference, then you almost completely remove the risk that the project goes south.

With software, there’s 100’s of moving parts that need to work together and not getting the right design from the get go can cause significant pain, cost and stress… In the worst case cause the code to be throwaway and require starting from scratch.

Of course “building” the software project is really only phase 1. Once built it takes on a new life and has a new set of requirements.

  1. It needs to perform well once released to the masses
    • Are the SQL/NoSQL queries as optimized as they can be? Are new DB indexes needed, or further DB normalization?
    • Are the loading/rendering response times as fast as they can be?
    • Are there any wasted code paths that are chewing up CPU, Network, Memory, or bloating data payloads etc. that should be cleaned up?
  2. It needs to be maintained, adapting to changes in the business requirements over time
  3. It needs to be flexible (code design wise) to handle tweaks and changes as part of #1 and #2 above

So what’s the moral of the story? Well in short, I’m fully behind the GTD mantra when it pertains to getting focused on solving a problem and working fast & hard on a solution. However it is really key not to get caught up in the excitement and “just start coding” without working out the key requirements and implementation details.

If you or your teammates are diving in without *really* knowing what you are building, there’s a very high risk that it won’t be the right thing.  You’ll either have to throw that work/effort away, or you’ll end up with a poor and/or cumbersome solution because you went too far down the wrong path and didn’t have enough time (or courage to admit defeat) and go back and start over.

This is where the GTD mantra can get you in trouble… and let’s call a spade a spade… Where the Agile “build, fail fast, iterate” can get you begging for mercy too.

So how do you detect when your project’s planning is being skipped? Here’s the telltale signs:

  1. If developers are anxious to build “part a” and worry about “part b” later… But there are aspects of “part b” that affect how “part a” should be designed or work… You need to stop and plan.
  2. If developers are not asking about or clarifying the ambiguous multiplicity of business entity relationships before coding… You need to stop and plan.
  3. If anywhere along the development process a developer says they can’t do “X” because the just built model/data structure doesn’t support it… You need to stop and plan.
  4. If the UI (User Interface) can not do what it needs to do because it is missing key information… You need to stop and plan.

I’ve seen developers that have worked on small projects plow ahead and duct tape their way through an implementation but in the real world of business / enterprise software development these are the things that kill progress and create fragile software if not caught early.

An hour of planning now can save you weeks or months down the road if you have to go back and re-engineer something that you built wrong because the plan wasn’t there or complete.

(Plan, Build, Test), Iterate


Why are Small Development Teams so much more Productive?

For anyone that has read “The Mythical Man Month” this should really come as no surprise but there is a very simple way to see and understand why the larger the team you have – the slower you’ll actually develop.

Its all about communication.  In an ideal world every member of the team will share everything they are doing with the rest of the team and each of them will share their updates with everyone else.  In this scenario everyone would know what is going on and there wouldn’t be mistakes or duplication due to lack of communication.

In fact when you develop by yourself (team of 1) there’s not even the possibility of communication issues because you have no one that you need to share info with… and no one you depend on for critical data.

If your team is 2, you have 2 channels of communication to maintain… A to B… and B to A

Team of 3? now you’re up to 6 channels… and it keeps growing exponentially.

Even with a team of 10 people your communication channels jumps up to a massive 90 communication channels! # of channels = (n * (n-1))


So whenever you are embarking on a new project try to keep the team size as small as you can while still enough to be effective.  If your team is part of a bigger organization be sure to have a “Point Person” that is the one who interfaces with other teams to both broadcast updates and collect any info from external sources that is to be passed to the team.

Managing Communication is key to not getting caught in a project that just seems to stall and run in circles.

The 40+ year quest to improve the numeric input control

I hereby present a challenge to the Internet…

Challenge: Design an improved numeric input field that could trump the 40+ year version we’ve all used… the standard horizontal string of digits.

Over time software developers have improved many fundamental aspects of graphical user interfaces constantly raising the bar for both design & usability.

We now have several enhancements on input controls that have become standard. Date inputs present calendars, Integer inputs contain spinners, multi-line text inputs contain character counts and auto expand to not require scrolling etc.

However dealing with numeric input is much more tricky. There’s some improvements that have been made in mobile for numeric inputs to present the numeric only keyboard… But beyond limiting the input to digits and decimals there isn’t really anything you can do to improve the actual input control.

Realistically here’s the set of constraints a numeric input field should be able to handle.

  1. The field must accept any valid number input between Negative Infinity and Positive Infinity
  2. The field must accept decimal values
  3. The field must support input from the keyboard (physical or software based)
  4. The field must support pasting input from the clipboard (on OSes with a clipboard)
  5. The field must support dragging input from elsewhere in the OS (on OSes that support this)
  6. The field should support locale based input, thus 49.99 in English could be entered as 49,99 in French locales

I’d argue that the first 2 bold constraints are hard requirements, and that the remaining are softer, ideal requirements

The shear number of possible values that a user could enter is truly infinite… and here in lies the rub… trying to design a specialized input control for data input of an infinite number of possibilities doesn’t allow for providing a special, customized control.

Don’t get me wrong though as soon as you alter or remove any of those constraints above other options do become available.

e.g. If you need to provide a field for input of an integer value between 1 and 10 you could use a <select> element to constrain input.

Or with HTML5 you could use an <input> of type range that can present a visual slider.

Neither of these allow for pasting in input but one could argue with such a small range of input this paste option feature is less of a need/requirement.

So… do you think you can come up with a better design that increases usability while handling the required constraints?

I’d love to see what ideas or creative solutions you might have.  I’ll admit I’m pretty adamant that there simply isn’t a better option, however I’m totally open to, and would love to be proven wrong too!

Programming Rule #3

“Thou shalt always leave the code cleaner than when you found it.”

If you’ve ever had to work on a medium to large size code base you very quickly learn that the level of effort to maintain such a beast is indirectly proportional to the level of quality and cleanliness of the source code.

Every dirty hack, every one-off, every “chunk of ‘this-is-just-temporary’ code”, every badly named variable/method, every bit of sloppily formatted code makes maintaining it that much harder.

As a result you get into a mindset that you are dammed & determined that you will not let code rot on your watch and you start to do everything you reasonably can to prevent it.

If you’ve never worked in a wide-sweeping role that brings to light how the little issues become big problems… trust me they do. One badly named method becomes several hundred badly named methods in no time flat, and suddenly you now have a confusing and complicated API due to the lack of foresight.

The end result of learning about the “Broken Windows Theory” (the problem this rule is solving) is that you very quickly adjust your approach and work extra hard to ensure that you do your 110% to ensure it not only doesn’t get worse – but it has to get better… even if only just a little.

When you come across a file, no matter how you got there… if you see a problem you do something about it.

  • Bad spacing or indentation?…  you FIX it!
  • Inconsistent attribute quoting?… you FIX it!
  • Funky statement formatting?… you FIX it!
  • Risky error prone code?… you FIX it!
  • Dead, empty or commented out code blocks?… you DELETE them!
  • Useless comments?… you DELETE them!
  • Redundant line breaks?… you DELETE them!
  • Trailing whitespace?… you DELETE it!
  • Badly named local variables?… you RENAME them!
  • Unused variables?… you DELETE them!
  • Typos or grammatical errors?… you FIX them!

The 30-60 seconds of your time to attack these problems will save many minutes for every future developer that looks at this code and in time save aggregated hours or even days of time and frustration for future developers attempting to debug when something goes wrong.

You’ll notice that many of the above issues are resolved by deleting code.  This is a good thing! In fact you’ll find that there is very little in programming that is more satisfying than deleting code! Just ask Jeff Atwood (aka @CodingHorror)!

Related: Programming Rule #1, Programming Rule #7

Every Web User Deserves Usable Form Controls – Even in Internet Explorer!

As a Web App Developer – Internet Explorer is the browser we love to hate.  However end users that use Internet Explorer (by choice or by force) shouldn’t have to suffer poor usability when we can do something about it.

The usability item I want to mention today is with regards to <textarea> elements.  Conceptually the textarea field is dead simple, a multiline text field control… but it is the little details that really matter.

The 1st problem is that by default IE renders textarea controls with a disabled vertical scrollbar when it isn’t required. Visually it is just extra noise and consumes valuable space, but it is also potentially misleading as it implies that the field itself might be disabled.

However the 2nd problem is that IE didn’t keep up with the times as browsers advanced.  All other browsers have added a usability tweak enabling the user to stretch the textarea to their desired width/height so they can see more of the content in the textarea or shrink it to see more of the surrounding screen.

I’d love to see the stretchable textarea become a native feature in Project Spartan (the new browser from Microsoft (think IE12)) but even if it never makes it in – we can always apply a little JavaScript magic to bring the stretchable feature to Internet Explorer!

Presenting StretchableTextareas! a jQuery plugin I wrote (MIT license) that adds a simple overlay to mimic the gripper in other browsers (see screen capture below).


Go ahead and download/fork the StretchableTextareas jQuery plugin code on Github.

Required Web Developer Toolbox Item Number 3

Opening the Toolbox

Every developer (and in particular) every Web Developer should have several tools in their toolbox.

I’ll reserve #1 for their assorted Web Browsers + devices, and accept #2 for their favorite text editor (Sublime, HippoEDIT, Notepad++, etc.) but that leaves us with the #3 slot open.

I think this is where every developers next tool depends more on their personal approach to development and what role they are filling that day etc.  If I’m doing graphics today then PhotoShop is my next weapon, Schema refactoring? then that will be my DB management tool… or based on how long it stays open when we are coding maybe its our console(s)?

However there is one tool I think is really important to developers that gets overlooked and that’s because you typically have to write this tool yourself – and its different for everyone!

Welcome to Searching your code base!

Search & Replace with our friend Regular Expressions

On the surface this is a super easy concept… you want to:

  1. Find all occurrences
  2. of ${someValue}
  3. in files of type ${theseFileTypes}

So you put your grep fu to work using whatever search tools you like, possibly with a funky regular expression to find that dynamic/variable value that you are looking for. It works great, you find everything you’re looking for… right?… wrong!

Sometimes you can’t find what you’re looking for because basic searching is quite limited and as powerful as they are, Regular Expressions have (IMHO) a severe limitation in that you can’t search for:  (find this)(but not this word)(followed by this)

You can abuse a RegEx to find matches that don’t contain a word… (great example answer) however you will always want to find stuff before/after it and thus it all starts to fall apart.

Other things that aren’t simple to find:

  • All files containing ${keywordA} but not ${keywordB}
  • All files containing ${keywordA} somewhere in the file after ${keywordB}
  • All files containing ${keywordA} without ${keywordB} directly following it

In the case of HTML files (regardless what language you use to generate them) there’s things you might want to be able to check for that go well beyond basic searching. How would you do some of these?

  • All files that define ID attributes (e.g. <div id=”foo”>) but only those that accidentally generate duplicate IDs… and if so list which IDs are duplicated
  • All files that include a specific JavaScript file but don’t contain any calls to the functions defined in it
  • All files that include 3 specific components in any order

The solution is both obvious and just painful enough that many developers give up and don’t attempt to solve the problem – heck I was one of them… for years!

The Solution:

The solution is to write code to do your dirty work😉 the language you use doesn’t matter as long as you can fairly quickly script up what you need including:

  • Recursively search your project directory of files (and be able to cap/control iterations)
  • Filter by multiple file types
  • Search multiple keywords (simple & RegEx)
  • Track and compare result findings
  • Output some sort of a log of all the findings

Although you might be thinking… what about the ability to make code replacements? You’re right that would be a bonus but if you get too caught up trying to handle that part (which can double your overall effort) you’ll likely give up or risk causing damage to your code files due to a corner case condition you weren’t expecting.

The good news is that omitting the replacement part actually doesn’t matter because once you have a log of files matching your query its easy to load them in your favorite editor and then run search & replace across your open files as needed.

My Solution:

As I said the language you use doesn’t matter. I went with something easy, it works with the tools I already have at hand, & requires no compiling… PHP!

I’ve created several “base” scripts that are easy to extend/edit as needed for any task at hand and whenever I need one I just hit that file’s URL in my browser and let it do all the hard work😉

I’ve hosted the base files for this up on GitHub in  a project called ProjectQuery (under MIT License) feel free to grab them and start building your own collection of custom code searching tools!


Apple Store – Genius Bar Appointments

I’ve always found the process for getting a technician or technical support at Apple to be a fair pain in the butt.

When you need to get a problem resolved you want to get it resolved right away… yet you can’t – you need to go online and book an appointment.


Then you need to visit the actual Apple store, wait in line again in order to see a “Genius”.

Sadly while “in line” you witness everyone else with their problems… broken screens, home buttons jammed, power buttons that won’t work, dead speakers, won’t charge, etc.

It doesn’t give customers the best perspective on the “quality” of the products when everyone you’re forced to wait in line with is having tragic issues.

What can you do while you wait?

Well I decided to write a blog post! (so far my wait is 30min) – so glad I booked an appointment!

Ugh… maybe it will get faster when customers are bringing in their broken Beats By Dre headphones😛


Update: So while I was waiting to get my unit replaced after finally getting to the Genius Bar… a classic case of a broken home button and they can’t just fix that, gotta replace the whole thing!.. oh and it is passed our 12mo warranty period… so… pay up :-(  the poor woman beside me was trying to get her iPhone replaced as there was no way it was going to be fixable.  Her issue was a bit more drastic… overnight while she was sleeping her iPhone was charging… that is until the middle of the night when the iPhone/battery short circuited and caught fire! Holy smokes! (pun intended) was she every lucky that she woke up as the parts she brought in in a Ziploc bag had clearly melted under intense internal heat. Luckily just the device melted and herself and her furniture/house were all fine.

I’m sure this was a fluke occurrence and not typical of iPhones but what scared me more was that the technician (once it was plainly obvious this was going to be a “no-point-in-arguing-this-will-be-a-free-replacement” situation)… ran the customer through a “standard” questionnaire to properly file the issue.  This “standard” questionnaire included references to “putting the fire out” and “fire truck”… yes “fire truck”!!! (obligatory Bobcat Goldthwait YouTube link) – How many times do fluke occurrences have to happen before they make it into the “standard” questionnaire?😉