Jason's Notes About Stuff

Kanban, or かんばん in Japanese literally means "signboard". The term comes from the manufacturing world. Implemented first in 1953, it was the precursor to the JIT (just-in-time) manufacturing process used throughout the world today. In software development, Kanban has slowly been replacing Scrum as the Agile methodology of choice since about 2010. The core of Kanban for software development is the Kanban board. This is simply a tool that makes the project status visible to all project members and stakeholders. The simplest Kanban board has three columns: The To Do column is a queue. Doing is a WIP (work in progress) column. And Done is a final state. Here is a much more complicated example with 8 columns and many sub-columns: On both charts, the principles are the same: Work moves from left to right Columns can represent queues of work to do , or work that is in progress There can be limits on the number of cards in each column Work is treated lik...

A recently published article, " The Secret Startup That Saved the Worst Website in America " details some of the problems with the  Healthcare.gov launch fiasco that "so bad it nearly broke the Affordable Care Act." It also outlines how a small team rewrote much of the software "working as a startup within the government and replacing contractor-made apps with ones costing one-fiftieth of the price ." A key point is something I've written about before, namely that one good programmer equals an infinite number of mediocre ones . A handful of bright , motivated programmers can easily beat a massive army of corporate drones , middle managers and bureaucrats. This is related to Brooks' law , which states that " adding manpower to a late software project makes it later. " Or in other words, " nine women can't make a baby in one month. " "The government’s method of running software turned on a sequential des...

As a technologist, the recent Apple vs. Samsung lawsuit  is extremely concerning . I was hoping all of this software patent nonsense would go away, but Apple just proved that the new business model is more about litigation than innovation . As a company that essentially  "stole" the entire desktop GUI and mouse concept from Xerox, you have to wonder how they arrived here. Ironically, this concept was subsequently "re-stolen" by Microsoft to create Windows -- one of the most ubiquitous, profitable pieces of software ever. Naturally, Apple  sued Microsoft in 1988 , a long and bitter lawsuit that wasn't resolved until 1994, when Microsoft won . In the midst of this, Apple was actually sued by Xerox , a suit that was dismissed. In the Apple vs. Microsoft ruling, the court stated: "Apple cannot get patent-like protection for the idea of a graphical user interface, or the idea of a desktop metaphor." They obviously took this to heart, ...

Do you have any problems? I sure do. Tons of them! Everyone has problems. You might even call them "challenges" or "puzzles" or "opportunities". I use an incredibly complex, patent-pending 3-step methodology for dealing with them: Identify Plan Do This may seem like a very  simple idea, but I assure you, most people do not follow this. Everybody gets step 1. Most people know their problems. Then then add: Step 1.a) Worry about the problem. Step 1.b) Complain about the problem. Step 1.c) Make up excuses for not addressing the problem I call this the WCE problem-solving methodology -- pronounced "wuss" ;) I have news: WCE does not work. They are unnecessary steps. A few people get to step 2, the planning stage, but never complete that step. What about step 3: Doing -- the one that really matters? Hardly anyone ever makes it there. They're still too busy cranking out excuses. So next time you come across a pr...

It seems like only yesterday that I quit my job in Atlanta, Georgia and moved back to Canada to start my custom software development company, Syllogistic Software Inc. As it turns out, that was actually about seven years ago! In 2008, at the 5-year mark, I did some research about how long typical startups last.  I found the following heavily referenced article , claiming 55%, 60%, and 63% failure/closure rates in years 5, 6 and 7, respectively. These numbers aren't exact, but give a pretty good idea of how long typical businesses last.  Running your own business is not easy.  It requires good planning, great execution, awesome support from your friends and family, and just a little bit of luck . I was fortunate to have all of the above, but that still doesn't mean that it was smooth sailing the whole way.  There were lots of bumps, and a few times I was ready to toss in the towel and close up shop. I've put together a brief timeline of some of the major ...

I think one of the the biggest challenges with management (and perhaps life in general) is dealing with people who happen to be feeling lazy, and just don't give a sh!t at the moment. This seems to be particularly difficult with "boring" jobs, like call centers, retail, etc. How many times have you called up a company to get some information, do some calculations, fix an error on your phone bill -- but they just aren't into it ? Perhaps they haven't had their coffee yet, or stayed out too late the night before.  Who knows. Whatever the cause, you can tell they really and truly don't care one bit about what you need them to do. When it comes down to it, motivation might be the most important aspect of management. You could have the best processes in the world, but if people have no incentive to follow them, they won't . So what's your advice?  How do you manage people who are feeling Lazy And Don't Give A Sh!t?

How many mediocre programmers does it take to replace a good programmer ? The answer is: Trick question. No amount of mediocre programmers will ever replace a good one. Let's say your good programmer has a "productivity factor" of 1.0 . We'll take this to mean that he or she gets 1 "unit" of productive, production-ready software shipped per day. The reality is that even an average programmer might not have a positive productivity factor. If you look at their productivity over the long term, it might actually be something like -0.1 or lower, meaning that overall they cause more work for others than they actually complete themselves. They basically just slow the good ones down . Furthermore, every programmer you add to a project adds overhead -- both in communication and complexity of the code. So adding two mediocre programmers is even worse than adding just one. Software development is an extremely complex discipline that requires above-average p...

It's official! All of the paperwork for a one-year working holiday trip to New Zealand is now complete. Melissa and I will be leaving September 1st, and returning August 2010. I'll be continuing to operate my web development company -- Syllogistic Software Inc. -- while I'm there. We have invested a huge amount of time and effort into "virtualizing" the company. With clients in Toronto, London (Ontario), Vancouver, and Waterloo, plus employees in Kitchener, Montreal, and elsewhere, communication is paramount . Our infrastructure spans the Internet, including a full virtual PBX phone system with multiple extensions and IVR via Trixbox . All company email, shared calendars, and documents are hosted on Google Apps . Source code is managed by Subversion . The heart and soul of the operation is handled by an internal application we wrote, called simply the "Project Management System" ( Update 2011-07-13: This is now called PMRobot ). This allow...

People are getting busier and busier, and it is becoming somewhat of an art to actually get people to read and respond to emails. Here are some quick tips to make the experience better for both the sender and receiver: Make emails as short and concise as possible. Important: Write a concise, relevant subject line! Separate your short sentences into paragraphs with a space between them. If you are making multiple points, or asking multiple questions, put them in a numbered list .  Better yet -- write separate emails with different subject lines. Make sure it will fit on one screen of a typical email program. (a lot of people don’t like scrolling) Use bold and highlighting to draw attention to the really important parts. Edit your emails multiple times, and cut out unnecessary words and sentences. If your email requires a response, try summing up by asking one simple question at the very end of the email. People are great at writing long, rambling emails, but sel...

I read a nice little example of ROWE*-based thinking in a recent blog posting. (link to the full article below) ... Pre-ROWE Manager: “We’ve been working on this strategy for awhile, and I really want you to crack the nut this year.” Employee: “Got it. I’ll do my best.” ["I have no idea what you're asking for, but if I show up every day, stay late, and come to you next year with something that I think you might like, I should be okay."] Post-ROWE Manager: “We’ve been working on this strategy for awhile, and I really want you to crack the nut this year.” Employee: “Let’s define ‘the nut’. How will we know if I’ve cracked it? How will it be measured? What’s ‘meets expectations’ and ‘exceeds expectations’ on cracking the nut?” ["If I can get clear on how to exceed expectations on cracking this nut, I can figure out the activities that will get me there and also plan how I'll volunteer at my child's school, coach her basketball team, and take a vacation to ...

Robert X. Cringely wrote a nice little post about Leadership recently. Everybody has lots to say on this topic -- most of which is meaningless blubber -- but I was particularly impressed with these little gems (emphasis added): "Management is telling people what to do, which is a vital part of any industrial economy. Leadership is figuring out what ought to be done then getting people to do it , which is very different. It is a vital part of any successful post-industrial economy, too, but most managers don't know that. ... In contrast to the military, most businesses do a lot less explaining and pondering and a lot more laying down edicts. That's management, which works fine on an assembly line, but not at all well building a big software application or winning a war. " You can read the full article here: http://www.pbs.org/cringely/pulpit/2008/pulpit_20080917_005420.html

Today I experienced something I learned about in a Services Marketing course while doing my MBA at Laurier. It’s what’s called “Service Failure.” I’m sure you’ve all experienced it one time or another. This is when a service business promises you a certain experience, then fails to deliver. In this case, it was a not-to-be named local haircutting salon I’ve been going to for a year or so. I always make an appointment, arrive on time, and typically wait 10-15 minutes before being started on. Anyone who knows me is aware of my strict adherence to deadlines and schedules and my general annoyance at people who don’t. To me, making an appointment with someone is a promise that they will be available at the specified time, barring an unforeseen calamity. Nonetheless, I put up with the 10-15 minute wait because most places aren’t much better. Well, today I came in on time, as usual, and was told, “Just finishing up here. Have a seat and I’ll be with you shortly.” I sat down, texted a bit...

Scott Ambler has posted a follow-up on his previous article about fixed price software projects at http://www.ddj.com/architect/209602001. As a quick summary, he gives five recommendations: Give a ranged estimate (+/- a certain percentage or amount) Do some upfront agile modeling (using people who will actually do the work) If the customer still insists on a "precise" estimate, pad the number as much as possible to account for the risks Fix the price, flex the scope (anything added requires removing something of equal effort) Stage the funding, based on real deliverables (working software) More to come on this topic...

I had been putting together some notes to write a short article about the difficulties with fixed-price software development, but Scott Ambler beat me to it. I just read his excellent piece, entitled " Is Fixed-Price Software Development Unethical? " It's sure to spark some controversy. As he mentions, both academia and industry have been trying to figure out how to do this for decades now, and haven't had much success. The important thing to note is that he is talking about projects where the scope, schedule and cost are all determined upfront. To the inexperienced, this seems completely reasonable, but anyone who's done software development for long enough (10+ years) understands the problems with this approach: It is impossible to define a 100% precise scope upfront. The scope always changes. Frequently. Even with a 100% precise, fixed scope, your estimate will likely only have order of magnitude accuracy. Starting with a good estimate, the resou...

In the business world, there are phone people, and there are email people. I'll admit right upfront that I'm an email person. There are situations when phone or face-to-face meetings are necessary or more appropriate, but for most day to day issues, I think email is great. Consider this scenario: I send an email checking on the status of something. The other person gets the email, and realizes they need to ask me something that basically requires a yes or no answer. Instead of emailing, they phone me. Naturally, I miss the call and they leave me a long message re-explaining the entire situation, asking me the question, and leaving their contact information and the times they can be reached. I have to log into my voicemail, retrieve the message, listen to it (possibly more than once) and take down the contact info. Then I call them back -- and, you guessed it -- they're not available. By the time I finally get them tracked down and give them their answer, I've proba...

There's a great little article over at What's the next action about how to make an effective To-Do list. If you don't find making lists effective, it might be because you're doing it wrong! Some of the key points are: Use verbs: Everything on the list needs to be actionable, which generally means it should start with a verb. Be specific: If an action isn't specific enough, it's easy to defer it since you don't really know what the "next action" is. Group by context: Group your tasks by context. (at the computer, on the phone, running errands, etc.) Focus on "next": Filter out everything except the very next task for each context.

Tim Ferriss (author of the 4 Hour Workweek) recently posted a great list of "stressful and common habits that entrepreneurs and office workers should strive to eliminate." My two favorites: 1. Do not answer calls from unrecognized phone numbers (I never do) 4. Do not let people ramble (I almost always answer personal calls with "Hey, what's up?" and business calls with "Hi, what can I do for you?"

A couple of the worst possible ways you can manage people: Ostrich mentality (a.k.a. Head in the sand): Refers to the "ignore it and it will go away" attitude. Some managers think that if they just "leave it until next week" somehow the problem will just go away. No. It'll get worse. Act on it now. Ditch digging theory of management : This is the belief that every task in business is the same as simple manual labour (like digging a ditch). In other words, they think that to make a project go faster, they just need to add more people ("horsepower"). No. Often adding more people to a complex project will just slow things down. Some things just take time. Warm body theory of management : This is a personal pet peeve of mine because I see it everywhere. This is the belief that people ("warm bodies") in the office, sitting at their desk somehow equals productivity. Some managers frown on personal time, and reward people who are th...

A common problem with software development project management is that most people don't really understand how it works. Programmers are often likened to construction workers. Managers view them as skilled labour, like a carpenter or brick-layer. If you want something built faster, you hire more people, and things go quicker. Software engineering is a different beast, though. Fred Brooks wrote The Mythical Man Month in 1974, and it is often considered the "bible" of software engineering. In the book, he explains how creating software is different. Brook's Law states that " Adding manpower to a late software project makes it later. " It's important to keep teams small and agile, especially in the early stages when the architecture is in flux. Creating usable, high-quality software takes a lot of time, skill and experience. Trying to cut a deadline by adding more people will almost guarantee the opposite effect.

Estimating software development time is hard. There are so many variables, unknowns, "unknown unknowns", and the specification always changes. Besides that, developers tend to be optimistic by nature. Here's a handy little way to come up with a quick, yet accurate estimate: Come up with your best, overall estimate that you feel is realistic using your favorite technique, or pure "gut feeling" if you are a very experienced developer and you know the problem domain well. Ok, you have your absolutely realistic number now, right? It's not realistic. I guarantee you there are aspects you haven't thought of. Double the number. This is your best case scenario estimate. This is how long it will take assuming everything goes well and there are no snags or major changes along the way. Now double it again. This is your most likely estimate. This is how long the project will probably take, when all is said and done. Now double it a final time. T...