GigaOM Web Innovators Group: Boston Startups Come Out & Present «

I noticed this over on GigaOM GigaOM Web Innovators Group: Boston Startups Come Out & Present «. I noticed that a company called frevvo. This company was founded by a gorup of people I have worked with in the past. They have some cool technology that is worth checking out (I would describe it, but hey, go look for yourself!)

Advertisements

Why IT Executives aren’t embracing Agile

Wille Faler has written an interesitng post Why IT Executives aren’t embracing Agile, referring in turn to another post on the same subject. Given my background, and my current role, I think I can comment on a technology executive’s opinion of agile processes.

Over the years I have worked on projects using a wide range of processes. Back in the eighties I worked on a team of very bright scientists, writing software primarily for their own use. We had almost no real development process (at best it was managed chaos). This was also one of the most successful software teams of which I have ever been a part. I do not think this is repeatable in most software development environments, because that particular environment had a number of unique characteristics:

  1. Really, Really smart people, especially in the domain in which we were working (satellite control).  
  2. Staff Retention: nobody ever left. When I joined the team, most of the people there had been there, working on the same code for 15+ years. Most had written the original versions of the code, and invented the algorithms.
  3. The developers were the users of the software – eliminating alot of problems of capturing requirements  and expectations. It is pretty hard to have unfulfilled expectations when you are writing software your own software.

Shortly after that, I was was involved in a large military project (10 years, billions of dollars, hundreds of thousands of requirements). Needless to say, we had plenty of process. This was the epitome of the heavy process. Between the company I worked for, and the many subcontracting organizations, I was exposed to many flavours of software process (all of them heavy). I was also involved in ISO 9000 certificatiom programs, CMM assessments, 6-sigma programs and Design for Manufacturability programs (we did hardware, too). One of the things I learned in all of that was that you can have all the process in the world, and still fail. While having a strong software development process (whether it is heavy, agile, or otherwise) may vastly increase your chances of success, it by no mean guarantees it.

In the past 10 years, I have become a great proponent of “just enough process” – trying to take what I have learned from the heavy processes on the military projects, and apply what makes sense in a small, product-oriented environment, while leaving much of the “weight” behind. In the period from about 1998 through 2002 (the last time I directly managed development projects) I was greatly impressed with agile processes. While we never fanatically applied any of the agile methodologies, we did adopt many aspects, such as user stories, iterative incremental development, and test driven development. Some aspect just did not fit our environment (such as pair-programming). We had a fair amount of success using this approach, and many aspects of agile development are still in use.

Getting back to the topic at hand (why IT executives do not embrace Agile processes), from my perspective, agile processes are definitely viable and advantageous in certain contexts. Also, “heavy” processes certainly do not guarantee success. My feeling is that there is a time and place for both kinds of process. As in most things, it is important to have a number of tools at your disposal, and to have the knowledge of when it is appropriate to use these tools. Remember, an idea is a dangerous thing when it is the only one you have (didn’t I use that a couple of days ago?).

For example, I think it is entirely innappropriate to use “heavy” processes in small, commercial product development. Similarly, as an IT executive, I would be extremely hesitant to use an Agile process on a large, complex development project, because I have not seen sufficient evidence of the viability of the approach.

It all comes down to using the right tools in the right situations.

Hiring Programmers – the Good, the Bad, and the Ugly

I had a read through this A Guide to Hiring Programmers: The High Cost of Low Quality today, and found it very interesting. At a high level, I agree with the article, concerning the relative value of hiring the best, versus hiring whatever you can find. On the other hand, I have my own distinct opinions on this, and cannot resist sharing them 🙂

First off, despite the great content of the referenced post, the fact that it is buried in “Perl is the ultimate language” rhetoric is unfortunate. Whenever I hear anyone claim that any single language is the ultimate language, and that all enlightened programmers would use it if only they had the choice and the wisdom I get really worried (and frequently giggle). I am reminded of a statement I read once: “An idea is a dangerous thing when it is the only one you’ve got”. There is no such thing as a language which is perfect, let alone perfect for all applications and solutions. Over the last 25 years, I have programmed professionally using somewhere around 30 different programming languages. A fairly large number of those came with promises that they were the ultimate programming language. It was crap every time, and it still is. Give me a programmer with real world experience in many different languages (and many different domains if possible) every time. They have a higher probability of using the right tool for the right job, and can more easily learn new languages as needed.

Here are a few other comments I have on the hiring of programmers:

  1. Always hire the Best. This is, unfortunately, somewhat ambiguous. What does “best” mean? Does it mean the same things in all contexts? just because someone was the star of their last team does not guarantee that they will work out on your team, on your project. Also, time plays a big part. Can you afford to spend a year finding the perfect person (see point 4, below)? 
  2. Don’t hire programmers. Hire developers. While there are places on the team for hard core coding machines – people who live and breathe bits, people who can hold conversations in hex – I do not need a whole team of them. I need more rounded people (especially in a startup, where resources are tight and roles need to be flexible). I need people who can interact with users (i.e. paying customers), with marketing, with senior management, and who can understand the bigger picture beyond their debugger.
  3. More Education <> Better programmers. Many of the worst programmers I have met had Computer Science degrees from great schools. Many had graduate degrees. Some of the best programmers I know have little to no university education in software development. When I am looking for good programmers, or better yet, exceptional programmers, I am looking first and foremost for thinking ability. I want people who have demonstrated problem-solving ability. I am looking for people who know how to learn, and know how to explore things which are new to them without getting scared. I would rather have a competent programmer who knows how to solve real problems than a genius programmer who is all theory.
  4. You Can’t Always Get What You Want. Finding the people you need is never easy, and always risky. You always need them right now. You always need them to “hit the ground running”. Well, that’s not always the way it works out. You can spend a year trying to find just the right person, and after that year, you may still be searching. Sometimes it is better to find a smart person with the right raw materials (a smart new grad, or a smart person with a few years under their belt, but not the exact skills you want) and grow them into what you need. I have had a lot of success with this in the last 10 years.
  5. Years <> Experience (necessarily). I have seen resumes come across my desk from people who had been working for 10 years, but did not have 10 years of experience. They had 1 year of experience, 10 times over. I have seen people who had been working for 3 years who DID have 10 years of experience (not really, but you get my point).
  6. IT Analysts are not Product Developers. This is one I am shaky on, but I will throw it out there anyway. In my experience, most people who have spent their careers working in IT shops in big corporations have no hope of making as software developers in a product-oriented development team, especially not in a startup. There just seems to be some mental conditioning which makes it hard to do that transition.
  7. Never underestimate the impact of a BAD developer. We have all hired them. People who for one reason or another do not work out in our team. Maybe they are idiots. Maybe they were burnt out on their last job. Maybe they are really good, but just do not fit in with the team or the project. Whatever the reason, never underestimate the impact they are having on your project. Their productivity will suck. Their presence will bring down the productivity of those around them. They can kill the morale of your team (which can be pretty fragile to begin with). Get rid of them. Take action sooner than later. If you think you can save them, take action in that direction, but set hard deadlines for improvement. If it comes down to it – get rid of them. Ultimately, you, your team, and probably the misfit employee, will all be happier for it.

I probably have more brilliant wisdom on this subject, but hey, it is midnight and I am supposed to be on vacation!

Oh – one last thing. The comment “It is the difference between Apple and Microsoft” is a mindless generalization, and is not worthy of the rest of the post. Microsoft has many groups of very talented developers turning out great code and great products. So does Apple. I would only say that Apple seems to have a distinct advantage in design – and I suspect that comes more from an all-pervasive culture than from hiring practices.

Usability Rant – Searching the Web for Documents, and saving them locally

I spent much of the morning (as I frequently do on weekends) doing research on a topic which has caught my interest through the week. I use a number of sources – sometimes just a web search, often a more targeted search like ACM’s or IEEE’s digital libraries. Usually, I do not read the documents I find right away. I like to search, find a significant number of interesting papers, and then I transfer the documents to my Tablet where I can read them, mark them up, and take notes.

This morning I was searching one of the digital libraries (I will not say which one, because I do not think my issue is with a specific library, as much as with the whole web), and saving the documents out to a sub-folder in my Documents folder under Windows Vista. So, the sequence of actions was like this:

  1. Perform a keyword search on the topic of interest
  2. Start looking at the list of hits presented 10 at a time (like almost all web search – I have already talked about how much I hate this model)
  3. I click on the available PDF to view it, which opens another browser window (Rant #1: I cannot right-click and save this document because the link does not point at the actual PDF, but to some sort of delivery system).
  4. In the new window, I am asked to authenticate myself for this content, even though I have already authenticated when signing in to the document library site (this is Rant #2).
  5. Having re-authenticated, I finally get to see the document (in the latest Abobe Reader UI – which I am not too fond of either – maybe it will grow on me).
  6. I click the button to save a copy of this PDF, and a File Save dialog pops up. (Rant #3: Every time I go to save, it defaults to my Documents folder, as opposed to remembering where I saved the last dozen or so documents. Rant #4: Where ever the focus is in the File Save dialog, it is NOT in the list of documents and folders – so I start spinning my mouse wheel to scroll down and find the folder it should have defaulted to in the first place, only to notice nothing is moving, so I have to click in the list box, and then start scrolling. Rant #5: Wouldn’t be nice to have a button somewhere, similar to the Save and Save As buttons, but which allowed you to “Save this to the last place I saved stuff and where I have been saving stuff for an hour”, in one click?) 
  7. About once every 5 or 6 saves, for some reason it DOES remember what folder I was saving to, which is a good thing, but because it is not consistent, it further interrupts the rhythm of my work. (this is Rant #6)
  8. Periodically as I am going through the search results (in that annoying “10 at a time” list), I will click to view a document and once again be prompted to authenticate, presumably because my session has expired or something. (Rant #7: This should not happen. I have not been away from my keyboard, and I have not paused my work in anyway. The session time-out should detect that I have been active all this time, and should reset. I should not have to repeatedly re-authenticate.)

Admittedly, these are all minor issues. Individually, they would seem not even worth talking about. Together, however, they destroy the overall experience of what I am doing. The destroy my train of thought. They force me to break out of thinking about WHAT I am doing, and think about HOW I am doing it. They waste my time, a fraction of a second at a time. And they annoy the crap out of me!

The sad thing is that this is not an isolated experience. This is the norm, rather than the exception. The computers and software upon which we have come to depend, and which are supposed to make our lives easier, on a frequent and consistent basis, rudely interrupt us with stupid questions and inconsistent behaviour.

There is constant talk in the technology world about “the next big thing”. I, personally, would be thrilled if the “next big thing” were a concerted effort by the technology community to make the current big thing WORK PROPERLY!

The Future of the Tablet PC (does it have one?)

Reading a post by Loren Heiny, Will the Tablet PC find a new advocate?, got me thinking (again) about the future of the Table PC – more worrying about whether the Tablet even has a future. I am worried that because of the complete mess Microsoft has made of marketing the tablet platform, without Bill’s continued visible support behind it, the Tablet will either disappear, or be relegated to a very narrow niche product.

I think I have mentioned (over and over) that I am a big fan of the Tablet PC. I think that in many respects it is far more innovative than anything to come out of Apple in the last 10 years or so. And in terms of the industry as a whole, it has opened up both a hardware and potential software market well beyond Microsoft (take note of that all you Apple fans – what has the ultimate closed source community at Apple produced that has benefited any business other than Apple?).

The problem now, of course, is that the Tablet is old news. It is 5 years old, has not lived up to early predictions that soon “every laptop sold will be a Tablet” (though in real terms has been reasonably successful), there is a shortage of really “tablet specific” or even “tablet aware” applications (notable exceptions of course are OneNote and MindJet MindManager). It has really missed the boat on the hype cycle it could have generated. And now, the primary champion of the platform, Bill himself, is no longer involved in day-to-day operations at Microsoft.

So, whither the Tablet PC? Loren makes a number of good points in the referenced article – and I will not repeat them here (hey, go read the original!). I agree whole-heartedly that the fact that those of us who support the Tablet PC have our work cut out for us if the momentum is to be maintained. I have been looking for projections about the size and growth of the Tablet PC market, but doing a Google search I do not see anything that is newer than about 2004. Are there any more current projections out there?

Another thought I had, beyond Loren’s observations, is around open source and the Tablet PC. The hardware specifications for the Tablet are fairly well defined. Unfortunately, the only software that supports it is Windows (not that I dislike Windows, but it means the entire Tablet PC industry is at the mercy of Microsoft’s decsions about continuing the platform). how about some of these really innovation open source types take the Tablet PC to new heights? Lets create a Linux-based (or not) OS, put a novel, Tablet-specific UI on it, and drive the Tablet market in that way? I know there are people out there who have put Linux on the Tablets, but I am talking more than just getting so it doesn’t crash, and works like a laptop with a funny shaped mouse. Something that really IS a Tablet computer. That would be a really innovative use of Open Source!

Thoughts?   

Fluffy Red Towels

Ok, so what do fluffy red towels have to do with software development, innovation, or usability? Let me tell you a little Monday morning story….

Last weekend I was swimming in the pool (which is exciting in itself, since a week earlier we were under a heavy snowfall warning!). When I got out of the pool, I grabbed one of the new towels my wife bought recently. I was thinking to myself “wow – these are really nice towels – nice colour, very fluffy, and very, very soft to touch.” I was impressed. After a few minutes of towelling off, I realized something was not quite right. I was not getting any less wet. Perhaps it had started to snow again? In reality, the towel just was not absorbing anything at all. It seemed to be like one of those shirts with the spill-resistant coating – a nice feature in a shirt, but not quite so nice in a towel. The towel, despite being very nice in appearance and superficially pleasant to use, failed to fulfill its single biggest functional requirement – you could not dry anything with it!

It occurred to me that this is a good metaphor for much of what goes on in product design – in software and elsewhere. Many products which do take into account usability and user experience, do so at the expense of functional design (yes, realize that there are even more products out there which implement functionality and ignore the user altogether). This brought home to me an important fact: as important as usability is, it does not mean squat if the product fails to fulfill its functional requirements.

Fewer hurdles

One of the best sales guys I know told me that a large part of the sales process is removing objections on the part of the buyer. I guess one of the best ways of removing objections is by gettting rid of hurdles before they become objections.

MyMicroISV has an interesting post on 13 Fewer hurdles = more micro-ISV sales. I whole heartedly agree witht he items he lists. It amazes me (not just online, but in the real world) just how hard businesses sometimes make it to buy thier products. A case in point would be when I bought my current Tablet PC. It took (seemingly) forever to find a way to buy, mostly because the vendor seemed only to want to sell as part of vertical solutions. A consumer wanting to buy a tablet just did not seem to fit thier model (I think that this is a problem with the whole Tablet PC marketing scheme, but that’s another story).

When thinking about removing these hurdles, it occured to me that the same philosophy cold be applied to software design. How many of the programs do we continue to use which annoy the heck out of us, only because they are the only option, or the least annoying option? How many opportunities exist for just, plain good software, that does what it is supposed to do, without annoying the user? This goes back to what we all used to be taught as part of our first-year programming courses: Keep It Simple, Stupid! (I wonder, do they still teach this?).

There is a very great focus now on adding features, making things prettier, going for the latest whiz-bang bells and whistles, when in reality, what is most needed is software that just works, and does so without being annoying. This seems to be a great opportunity for the Micro ISV model.

 How hard can it be?