Kablingy

I cringe when software developers say that there's a bug in the software. It feels like the developer is shrugging off any responsibility about the matter, as if a moth randomly flew into the computer and started to swap ones and zeros about.

In fact, the developer has created a fault, error, mistake or defect in the software. If you determine the root cause of the defect, its usually because the software wasn't tested adequately, the developer used risky programming techniques, and he/she didn't have a second or third pair of eyes reviewing the code. 

It's a reflection of the general lack of professionalism that the software developer community exude. We're not accountable for our actions, so we brush of our mistakes by saying a bug flew into the code.

So developers, please take responsibility for your code. You created a defect, not a bug.

I attended Startup Weekend Dublin 2010 along Kevin Noonan, Darragh Curran, Declan McGrath, Sean Coughlan, and Mike Hughes. You have to build a business in 2.5 days. Good fun had by all.

Lessons learned:

1. Meet your team before-hand

2. Stay disciplined and follow good practices. Integrate software often, test your code, keep your code clean, pair program, and have quick stand up meetings. It'll pay off in the last few hours when panic sets it.

3. Your execution of the idea doesn't really seem to matter to the judges. It's your business case and how 'novel' your idea is are the things that get the bigger points.

4. Bring a DVI monitor connector so you don't look like an idiot when you try to do your presentation on your macbook.

We got 3rd place for classometer.com. We plan on getting it ready for the world soon.

I often hesitate to build trivial Rails applications. The reason is hosting. Sometimes the overhead of setting up a new virtual private server, securing it, and updating it regularly turns me off wanting to make the application in the first place. It costs time and money to pay for the server, which is an unpleasant cost to have to pass on the customer especially when the application is small.

Heroku has changed the game. If you want to write a very simple Rails (or indeed complex) application, you can deploy it for free to Heroku in no time. If you need a few extras such as hourly cron jobs, wildcard subdomains, then you can pay just for those features. There is substantially less fiddling around to be performed when deploying to Heroku.

I've deployed about 3 applications to Heroku, and it wasn't until the 3rd one that it became a smooth process. One does have to make adjustments to one's development environment such as hosting uploadable files on S3, running on Ruby 1.8.6, deploying to Postgres etc. It took quite a bit of jumping through hoops before I figured out how to deploy to Heroku effectively (so be warned)

But the net result is that yesterday I built and deployed a working tested Rails app from scratch for a customer in 1 day - definitely a record for me. 

Thanks Heroku and thanks to Darragh Curran, Declan McGrath, and Kevin Noonan for recommending it to me in the face of skepticism

(screenshot taken from www.heroku.com)

This is based on a few horror stories we've heard from customers recently, who were unhappy with their previous software provider.

Here are 5 questions we think most software consultancies aren't asking their customers. 

1. What are you quantifiably trying to achieve?

Before you hand over your money for software, it's worth asking what you want to achieve from this investment. Do you want your new software to generate a 5% increase in foot fall? Perhaps you'd like €2000 per month deposited in your bank account while you sleep? If nobody asks you this question, then it's a little difficult to know if the software project was a success or not. If you don't think about how to measure success, then your software consultancy will undoubtedly claim it when the project is finished.

2. Why do you need new software and is there any existing software that would do the job? 

Another way of asking this question is "What would be 90% as good, but would be 10% of the cost?". Quite often, a combination of some existing software services e.g. Highrise, Dropbox, Youtube & Overtake (shameless plug) will allow you to achieve most of what you want at a fraction of the price of a perfect, custom and expensive software solution.

3. What is the absolute minimum feature set you need?

If you have a new idea for a software service, and you're not sure if it's going to work, then don't invest upfront in unnecessary features. For example, there's no need yet to build a fantastic user administration and reporting system. Why? Because you don't have enough users yet to necessitate it. You don't have any data to put into the report.

Remember that most software consultancies will be happy to take your money and build unnecessary features for you.  Also, forget scalability for now. You don't need the $1000 hosting package, yet. Concentrate on the bare features needed that will give you the feedback to know if the project is going to be a success or not. If a project is destined for failure, kill it as early and as cheaply as you can.

4. Who are the different types of users?

Identifying 3 or 4 archetypal people by name that will use your software is invaluable to the design process. Speaking in terms of what "Jim the account manager" or "Kate the sys-admin" needs is far better than always referring to The User, or as we call him - The Elastic User. If you build a system for the elastic user, you'll probably end up with software bloated with features. However, by defining user personas, you will be able to identify what features are important for what persona, which is the most important persona to satisfy, and more importantly what features can be eliminated from the system.

5. Who owns the code?

In our opinion, this question doesn't get asked enough, even though it's pretty simple to answer. If you pay us to build custom software, you own the code. If you use one of our software subscription services, then we own the code for the service and you own the data you put into it. We also recommend that you pay for the server hosting directly, and own your website domain. This will avoid any unpleasantness if and when you want to switch software providers.

It's a good idea to have a section covering these points in the Master Services Agreement with your software provider.

You do have a Master Services Agreement, don't you?

Recently I was in the market for a customer relationship management (CRM) tool. I wanted something to track leads, contact dates, and I wanted to store a plethora of custom information with each new lead/customer.

I tried out some open source tools, but they were too complicated for the job. Highrise didn't have what I wanted for this particular purpose. So I tried one out one of the CRM/SaaS market leaders. Let's leave them nameless for the post.

Within 30 minutes of signing up online to try it out, the sales staff phoned me. Holy moly, what quick customer service! Peter, the chap on the other end was delightful. He asked me all about my CRM needs, my business, and touted the benefits of his CRM online service. He was a genuinely pleasant fellow. I raved about the customer service after the call. Unfortunately, Peter set me up for a follow up call with... an account manager.

Enter the forceful salesman.

Bill the account manager emailed me 10 nanoseconds later eagerly looking to arrange a call with me. A day passed before I emailed Bill back. I had solved my CRM needs in the meantime with something much cheaper that his solution, and so I emailed him back to politely decline his offer.

This didn't suit Bill.

Bill ignored my email and phoned me back the very next day, clearly juiced up on one too many orange mocha frappachinos. He was aggressive, dismissive, and never gave up on the sale. He was everything what you would expect from a forceful salesman. I told him annual payments were so 2007, but he parried with quarterly payments.  I told him I disliked lock-in contracts and favoured 37 Signals style, 'cancel anytime' policies. He informed me that they'd be out of business in 8 months.  I told him his user interface was too complicated for me, he countered with the offer of an in-house demonstration. But my favourite part was when he turned IBM on me and started to talk codswallop about The Cloud.

The Cloud, man.

"Steve, you could have your leads integrated with your Facebook, your LinkedIn, your Twitter. If you don't leverage The Cloud, you're going to get left behind. The Cloud is the future of selling."

The call ended there as the cow manure detector was off the chart and I've been known to get belligerent towards the parties of fear, uncertainty, and doubt (FUD).  What a real shame that the whole affair spiralled from "What great customer service!" to "I'm gonna blog about this jackass"

In the meantime, our CRM solution which is a custom Rails application that we built, is serving our needs nicely. Let us know if you need some custom software done right.

[Warning, this is a programmer post. It gets Blurby!]

We’ve upgraded almost all of our applications to Rails 2.3.5 and Ruby 1.9. All things said, it was not easy.

So here are my top 5 tips for upgrading your Rails applications to use Ruby 1.9

The MySQL Ruby Gem

If you use MySQL, use this mysql-ruby fork by  Loren Segal. It wouldn’t install as a gem so I downloaded the code from GitHub and turned it into a gem. Email me if you want the gem.

The MySQL Database

The columns and tables in our databases had to be converted to UTF-8. These commands came in handy

/* Here's 1 command altering a table, and 2 commands altering the first 2 fields in that table */
alter table users character set utf8;
alter table users modify email varchar(255) character set utf8 collate utf8_unicode_ci;
alter table users modify crypted_password varchar(255) character set utf8 collate utf8_unicode_ci;
/* etc.... */

Then I put these lines in my.cnf

[mysqld]
init-connect='SET NAMES utf8'
character-set-server=utf8
collation-server=utf8_general_ci

UTF-8 + Rails + Ruby 1.9

Watch for UTF-8/ASCII problems. In combination with the above, I would advise

• Putting # coding utf-8 at the top of your ruby code
• Putting these lines into your environment.rb

Encoding.default_internal = 'utf-8'

Encoding.default_external = 'utf-8'

• [Update - 29/03/2010]  - Consider using these 2 patches to force UTF-8 encoding.

Maintaining Multiple Ruby versions

Use Ruby Version Manager. This is very useful if, like me, you have a number of Ruby 1.8 and Ruby 1.9 applications running. Ruby Switcher makes it easy to install new Ruby VM’s and switch between them.  Note, it installs Ruby 1.9 off your home directory. Edit the script to change this.

Test

All of our applications have a healthy mixture of Test Unit tests, and Selenium tests. Converting to 1.9 would have been terrifying without this safety net.  It’s been said enough already, but if you’re not testing your code, I would advise that you start now.

If you’ve any questions about converting your Rails applications to Ruby 1.9, just email me or comment below.

Today a van driver almost ran me over. (That’s him above). The details aren’t important, other than he was driving like a maniac in a business car park. It was a quick reminder that we can lose our lives in a flash.

An hour later when I started breathing again, it reminded me that a successful business is more than just the product. The product is probably the least important part. It’s about the systems used to build and distribute the product, the communications used to sell it, the legals used to protect it, and of course the cash flow.

Today’s experience reminded me I need to concentrate less on the product, and more on developing a system that allows me to be killed by an idiot in a blue van and the business keeps running fine without me.

We just returned from the 2009 Meath Enterprise Day, an event organised by our client and friends at Meath County Enterprise Board. Today we lent a helping hand by setting up some online surveys using SurveyMonkey where participants were entered into a draw.  It struck us shortly before the results were to be picked, that we had no elegant way to choose the results.  It was nothing that a little Rails application wouldn’t solve.

Half an hour later, and thanks to SurveyMonkey’s export features, we had this little doozy which allowed an independent judge to choose the winner.

The end result is hardly rocket surgery, but the feeling of having a daft deadline, several hundred onlookers, and no margin for error is still intense and exhilarating. Making a real world app in 30 minutes will test your programming kung fu and ability to focus under pressure. Try it!

P.S Congrats to the prize winner: Clayton Coyle.

As a consultancy,  how can we define project success?

Typically in a project, a client asks for features and a software development consultancy delivers those features, hopefully on time, on budget and to a professional standard. Then everybody claims success.

But how do we know if it was a success? Did we really fail? Could we do better than this?

We think the best way to address  project success is to first understand the project stakeholders' real requirements. The problem is that even the most enlightened agile developer can mistake features and designas project requirements. But by continually asking why, and not how, we can fish out what the client really requires. Consider the following example:

A sample set of  so called "requirements"

The client needs us to develop a web application with the following must have features:

• Users can sign up for free and upload and sell their own books
• Room for Google ads, and sponsors.
• User can upload their own avator and connect to  authors of the same genre
• Forums
• Integration with MySpace, Twitter
• Facebook App

This is not untypical of the kinds of applications we are asked to build. However, if we continually ask our client why (5 times will do the job) she wants these features, we might actually get to the real requirement which is:

The client wishes to increase her passive income by €2000 euro a month, within 6 months

Now that's a requirement and that's exactly where we should start the conversation.  Now we can start to talk about things like the business model  e.g.

• Why is she offering a free sign up? Why not charge her users a flat fee per month or percentage of the sales? 50 subscribers on a €40 a month plan will achieve the goal in a more predictable manner than advertising. Not to mention, can she realistically get enough traffic within 6 months to justify the advertisers fee?
• We might ask her if she would consider trying to aim her product at businesses instead of the consumer, since businesses are usually happy to pay for services, while consumers expect everything for free. Would she consider working with a dedicated sales team to get those 50 subscriptions within 6 months?
• Why bother inventing adding social network features when she could integrate with another established one or avail of a social networking platform service. Will the social network aspect help her to achieve the €2000 in 6 months goal at all?

And so on. You can see how this way of thinking can drastically alter the list of must have features from above. Perhaps the feature list now looks like this:

• Build a subscription based service aimed at professional authors. Authors get a shopping cart and microsite CMS with a spot for video blogging. Charge 40 euro a month for this service.
• Sample chapter of the book can be downloaded as a watermarked PDF
• Offer an auxillary service connecting authors with publishing companies

So coming back to the title of this post, how could we define project success? How about this.

• Get the real requirements. Make sure they have been quantified. If you're feeling saucy, you could even consider a requirements specification language like planguage. Don't be put off by the phrasespecification language, it's quite accessible really and not at all stuffy.
• Get your stakeholders to prioritise the top 10 requirements. Each requirement fits on an A4 sheet of paper. There's no need to mention features - that's for the design and development team to figure out.
• Drive the design from these requirements
• Then, do all of your usual wireframing, test driven development, iterative planning, continuous integration and all that good stuff etc.
• Measure continuously and communicate with your stakeholders on whether the requirements are being met, and thus if the project is going to be a success.

The masters in this department are Tom and Kai Gilb. Take a look at their site, publications, and free books for a wealth of information on requirements gathering and measuring project success. It's exactly what's been missing in the Agile software movement.

Getting started on a new project can be daunting sometimes. It can be difficult to know where to start when you first sit down with your customer and have to extract requirements from them in a structured manner. When I'm stuck, I mind map.

First I draw a central image with the project title.

Then I draw a branch for Users. I will start to ask about the different kinds of people that will use the application I'm about to build. These days subscription based web applications are all the rage, so that means there's usually at least  3 personas can be identified. So I'll sketch up Barbara the account owner, Julie the web application administrator, and Bill the customer.

Inevitably, that quick discussion will help me to spot at least 5 domain objects. So now I can do a little boxes and arrows diagram of the object relationships between User, Account, Subscription,Plan, Role. As we run through the scenarios of each users, more domain objects present themselves. During this discussion we might also identify more users which we can add on to the Users branch.

I usually draw a branch for business model also, as I really want to understand how the web application is going to make money. It’s a top priority for me that I build just enough software so that the client can get a ROI as soon as possible. Otherwise I run the risk of saying yes to every feature and building an application that doesn’t generate enough income to cover its initial investment. That's bad.

In mind mapping the business model, the users and their scenarios, and the domain model, the project will start to take shape very quickly. Mind mapping around the whiteboard is also a great way for your client to interact in this process. As you draw branches, she’ll immediately start to fill in the gaps of the map, and since it’s very visual and colourful, it sticks in the memory. You’ll find that you can wipe the board and redraw most of it from memory without even trying.

Give it a go – 4 markers and a whiteboard is all it takes. Don’t forget to take photos of it with your camera or phone before you clear it.