Productivity and Note-taking

I told a friend of mine that I wasn't really happy with the amount of time that gets taken up by Slack and "communication and scheduling" in general, and that on one particularly "noisy" week it had taken up around 7 hours. He said that was "hardly anything" and that most of his work was done via Slack.  He has a support role, so I guess that makes sense. So it definitely can be a useful tool, but in the past few weeks I've managed to keep Slack usage down to about 3 hours per week.

On a related topic, I've tried a bunch of different task management techniques over the years and none of them ever stuck. I've always ended up with a fragmented collection of things to do, scattered between various Notes apps, email-based task lists, Trello boards, and hand-written notes.  The problem with a lot of the software-based task management options for me is that they're not always in front of me and they take a conscious effort to open and use.

A notebook on the other hand is always on the desk beside me, usually open to the last page of notes. There's no effort getting to it, and I can easily glance over without disrupting whatever I was doing on the computer.

There's a system called a bullet journal for keeping and managing lists.  The website bulletjournal.com explains the system and has an online store with their BuJo journals that are designed to work with the bullet journal system. There's also an app, so for people who really want to get into it, there are a variety of ways. You don't need a special BuJo journal to start using the technique, however.

I've switched my list of tasks from an online document to my pen-and-paper bullet journal now. I'm not fastidious about keeping the journal up to date on a daily or even weekly basis, but I find that its just a lot easier to take notes this way than it was to type things into a digital form.  The only downside I can see is that it's harder to share than digital notes which can be copy and pasted. But frankly most of the tasks on my list are too detailed and boring for anybody else to care about. They just want to know how a feature is coming along, etc.  So, check out the bullet journal.

Slack is a major productivity drain

For the past few years I've been using RescueTime time management software.  It helps keep track of the different activities I've spent time on during the work week and stay focused on things that contribute to my productivity.  Another application that's become a big part of many workplaces is Slack. We use it for communication in my current team. A lot of times, it's really helpful. You can fire off a quick message and get a quick reply without really interrupting your main task. A lot of times you can ask a question, get valuable opinions from everyone concerned, and come up with a consensus that works for everybody, in a way that would've been impossible with traditional email and meetings.

Recently though I was shocked to see that Slack accounted for a full 7 hours of a recent work week. We've been doing a lot of planning and discussion for new feature work, and also working through some issues related to customer documentation, deployments, and things that are not specifically coding-related, so it's understandable that there's been more planning and discussion activity than usual, and less actual code-writing. But 7 hours!  My gosh.  That is a real time sink.

This was a wake-up call into something that I already intuitively knew, that Slack - as helpful as instant messaging can be - has the potential to be a black-hole where productivity gets sucked into a terminal death-spiral.

The challenge is how to reign in this Slack tyranny... if you don't monitor the conversations going on in various Slack channels, you're liable to miss out on vital information. A lot of people seem to think that broadcasting a message out on a Slack channel is "job complete" when it comes to communication - a surrogate for the old-school email.  That's not really the case; messages easily get lost in the backlog of noisy, run-on chatroom conversations.

I'm going to be keeping an eye on Slack usage and trying to figure the best way to keep it from sucking up a large percentage of my productive working hours without losing the benefit of instant communication with the broader team.  Maybe just being respectful of people's time and being a little less cavalier about using Slack to post casual commentary, understanding that Slack can definitely become a drain on my own and other people's time, and approaching it as a tool to be used with a certain level of professional self-restraint, might be a start.

When Agile Went Off the Rails

Whenever I hear a company say "We follow an agile development process", I can't help but wince a little. The core ideas of agile development are excellent, but somewhere along the way it accumulated quite a lot of codified process, and became its own formal methodology - almost the same thing the Agile Manifesto was trying to counteract. It's not too surprising, since the agile manifesto didn't prescribe any particular project management methodology for implementing its guidelines. So naturally it wasn't long before management professionals began to formalize agile philosophy into a methodology of their own.

Now one of the original authors of the Agile Manifesto has come out with a piece, originally titled "Time to Kill Agile", in which he makes this point that a formal methodology runs counter to the original goals of the agile development concept. Dave Thomas has been hugely influential in the software development field. Aside from being one of the authors of the agile manifesto, he's written a lot of other stuff, and he's the guy who coined the phrases "code kata" and "DRY" (Don't Repeat Yourself - the maxim developers follow to effectively organize their code).  He later renamed the piece "Agile Is Dead (Long Live Agility)!", which is a better reflection of his current thinking on Agile processes vs agile development's underlying goals.

Being a critic of Agile is risky; in many cases it seems to have improved the effectiveness of teams a lot. It's working for a lot of people, and they like it.

But having one of the original authors of the Agile Manifesto come out with this kind of criticism of agile methodology makes a certain amount of healthy skepticism seem appropriate.

Agile software development, according to Dave Thomas, can't be implemented as a set of methodologies, and the managers, consultants and companies that have sprung up around Agile have shown a certain level of disregard for what the authors of the Agile Manifesto intended in the first place.

Dave Thomas has some good advice for teams that want to develop software with agility. He advocates an iterative approach to development, and choosing options that enable future change. He recommends thinking of "agile" in the form of an adverb (agilely, or "with agility"). Programming with agility. Teams that execute with agility.

I've found that when it comes to managing a project, simple is usually better. What's worked best in my experience is, in a nutshell, to simply encourage communication. Make sure everyone understands the overall objective, how they can contribute to it, what progress has been made and what challenges remain, and importantly, give everyone the opportunity to have their work fully recognized and appreciated on a regular basis. Given the opportunity to work on a challenging project and the chance to have their contributions seen and appreciated by colleagues, most developers will bend over backwards to do their best.

One technique I found effective was a brief (timed with a hard stop) Monday morning meeting where we laid out the objectives for the week ahead, a quick information-gathering hike around the office at the end of the week, and an email re-cap on Friday afternoon highlighting the team's progress. Showing the percentage-towards-completion of major tasks was also a big motivator, as developers began to take pride in seeing their areas of responsibility make steady, visible progress towards completion.  We didn't formalize or get locked into one way of doing it, so when our company got acquired and our management structure changed, we adapted pretty easily.

Perhaps this isn't too far away from the way agile methodology is practiced "by the book". Regardless of the methodology, it's worth noting that the Agile Manifesto wasn't really a call to implement any particular process. It had broader goals in mind:

• People over processes.
• Working software over documentation.
• Collaboration over contracts.
• Adaptability over planning.

Windows 8 gets on the Web Stack Bandwagon

I'm a Mac / Linux guy, but it's good to see Microsoft putting some serious work into the user experience in the Windows 8 preview.  What's cool about the video on that link is that they've also seen the light when it comes to the developer experience, paving the way for rapid application development by leveraging the web stack of HTML5 and JavaScript.  A long way back I wrote about  "Gödel, Escher, Bach" to explore the link between artistic creativity and great engineering work - how a love of technical complexity drives some developers, compared to a love of elegance and simplicity that drives another kind of developer.  While technical complexity enamors the uber-geek, artists are inspired by technology that gets out of the way and allows them to do what they do best - create stuff.  Even though a web stack wouldn't be my first choice for some kinds of apps, it's just fine for a whole lot of them, and when it comes to rapid application development its way, way up high on the list of best options.

It seems like in the midst of Apple's incredible growth in the mobile, laptop, and tablet space there's been a lot of soul-searching going on at companies like Nokia, Microsoft, RIM, and many others.  A dominant theme that keeps coming up is "simplicity".  For example, see "Why Dropbox beat Syncplicity".  By embracing web technologies for app development  Microsoft is taking a forward-looking step towards simplicity in application development.  Hopefully this means standards-based web technologies and not the embrace-and-extend, proprietary model we have come to expect from Microsoft.

Things all seem to be moving in this direction.  RIM has a platform for building apps on web standards for the Blackberry.  The iPhone has had "web apps" for a long time.  And recently I've run into more people who are excited about Nitobi's PhoneGap, a technology I reviewed a few months ago (PhoneGap and jQuery Mobile First Impressions) which let's you build apps for 6 different smartphone platforms using standard web technologies

I think I just set a record for cross-linking to my own posts!  To make up for it next time I'll post a bunch of external links to cool stuff from the interwebs.

Tell CRTC to Reverse UBB

The CRTC is soliciting input from Canadians on anti-competitive Usage Based Billing practices by Bell, Rogers, and other incumbent ISPs.  The Open Media group has a convenient online form letter that you can submit to the CRTC.

http://openmedia.ca/crtc

Go the Open Media page and let your voice be heard by the CRTC!

When I wrote that "dumb is the new smart" in December, predicting that consumers would demand dumb pipes, it was before the FCC ruling on the merger of Comcast & NBC and the CRTC 2011-44 decision.

That CRTC ruling and subsequent public uproar has brought the issue to a head faster than I imagined.  Alas it seems that big ISPs like Bell and Rogers don't get it yet, but a lot of Canadians seem to think that dumb pipes are a smart choice. Yay! They're demanding it loudly, even if the big incumbent ISPs were too slow to see it coming.

Keynote Notes

Jobs is giving his keynote, introducing the next generation of iPods, iTunes and Apple TV.  One of the things I like, probably everybody likes, about Apple is their continual innovation.  One takeaway from the keynote is Jobs' description of the driving factor behind Apple's innovation and success:

We listened to what customers wanted...  This is what customers were telling us...  Our customers wanted this.

Apple delivers.  Cha-ching.

Can'tGro

The last canning plant in Canada to use Ontario-grown fruit is closing. What this means is that as of this summer, you will no longer be able to buy canned fruit that was grown in eastern Canada. CanGro, the multi-national corporation which owns the facility in St. Davids near Niagara Falls, has decided it is more profitable to move the entire operation to China, and will begin shipping Chinese-grown fruit to the Canadian market under their Del Monte brand.

This puts about 200 farmers in the Niagara region out of business, with a production of over 7000 tons of fruit annually. They no longer have a market for their produce. Hoping to save the industry in Canada, one farmer offered to purchase the CanGro factory if the fruit-canning contract would be returned to the local plant. He offered to put up $5 million dollars, but needed the Canadian government to match that amount to make the deal. The plant owners agreed to the deal. They agreed to give back the canning contract and met with the local farmers and government representatives. The Canadian government only had to pony up $5 million, and the Ontario fruit industry would be back in business.

But the Canadian government already had a proposal of their own: they were offering $30 million dollars for the farmers to rip up their fruit-bearing trees and burn them! I'm not making this up.

The deadline for the cannery purchase approached, and on the final day, there was still no reply from the Ontario's Minister of Economic Development and Trade, Sandra Pupatello. She was on a plane, on her way to China to attend meetings on deepening trade agreements with the Chinese. And much of the equipment from the plant had already been removed and was on its way to China to be used in the operation over there.

It would have cost $5 million for the government to help buy the plant and save the Ontario fruit industry, which in turn would pump a lot back into the Canadian economy, i.e. "economic development". Or they could pay $30 million dollars to rip the fruit industry out of Ontario by the roots, give it to China, and wipe out any possibility that the industry could recover in Canada, destroying thousands of acres of mature fruit trees in the midst of a world-wide food shortage.

They chose to spend $30 million tax-payer dollars to ruin Canada's fruit industry.

Sanda Pupatello, Ontario Minister of Economic Development and Trade, came on CBC radio, trying to offer an explanation.  She tried to say "The door isn't closed" on the Ontario fruit industry, that the government was "very interested" in finding ways to keep the industry in Canada, and that they were continuing to explore various options. She said that the deal to purchase the CanGro factory wasn't appropriate because the government felt they needed more consultation with "a broader spectrum" of representatives from the business sector and other interested parties. She indicated that the business plan wasn't as thorough as they wanted it to be.

Farmers are business people.  The large multi-national corporate "business sector" like Del Monte and CanGro care more about the profit margins they can realize by sending it all overseas.  Who's input should we really be listening to?

Starting Up

I recently made a decision to leave the company where I have been employed for the last 6 years, Bridgewater Systems Corporation, and become a contractor (gasp!) working with a very small group of high-tech entrepreneurs to form a new start-up. Starting a new company can be rather risky, and the golden age of startups in the Ottawa Valley may have passed, but its the sort of opportunity you don't get every day. There are a lot of reasons why I decided to do this, and as I was reading Hackers and Painters by Paul Graham, I began to feel even more like this is the right decision.

Graham gives an example of a galley ship, powered by 1000 rowers. He says there are a couple of factors limiting the speed of the ship. One is that the individual rower isn't going to see any noticeable improvement from working harder. The other is that, on a boat of 1000 rowers, the average rower is likely to be... well, an average rower. If you took 10 rowers and put them in a dinghy, their performance might double, because they'd be able to see the effects of rowing harder. And instead of taking 10 average rowers, if you took 10 of the best rowers, their performance might be 5 times better than average. The problem is when you can't see measurable results from your efforts.

The other thing Graham says is that you need leverage, which means the decisions you make will impact the success or failure of your endeavor. One way to tell if you have leverage is if making the wrong decision could result in a catastrophic failure.

These two things, measurability and leverage, are what Paul Graham says you need to contribute significantly to the wealth of society. And starting or working for a startup is how you get them.