People who read our blog will know that our first ever Hog Camp concluded last Friday. Hog Camp is hedgehog lab's internal Hack Day that runs over 48 hours and gives us a chance to build, experiment and work with tools and ideas that we would normally not explore in our daily jobs.
The biggest difference in Hog Camp from traditional Hack Days is that everybody participating works towards 1 single idea/solution rather than each individual or small teams working on their own. Our hope was that this encourages team work and help people build on the type of skills that are required in large teams (which is something we usually don't get in a small company like ours).
As expected, it was an intense 2 days of coding, design, discussions and beer+pizza which ended up producing some awesome results. We even managed to get people from outside hedgehog lab interested in the event and we are now opening up our next event to a select list of guests.
Presenting hedgehog lib....
The project our team chose to tackle for the inaugural Hog Camp was a web-based library system that allows us to manage our ever-growing book list and allow a painless and easy way to track their movement.
Unlike most Hack Day projects, hedgehog lib has a very practical purpose; it is going to be used on a near daily-basis internally at hedgehog lab. The core idea behind hedgehog lib was to build something within 48 hours that would have the following functionality.
Allow us to search for and add books to our library (using Google Book Search)
Allow the ability for users to register and check out/check in books to help keep track of who is reading what.
A wishlist feature for people to request books they would like in our library.
Although the final feature set includes a bit more than this, I am glad to report we managed to build and get to a first version of a usable product.
A sneak peek
Free as in free beer
Although hedgehog lib is a great first version, there is plenty of scope to improve the solution and customise it for various needs. To keep with the spirit of the event, we have decide to open source all our future Hog Camp projects in the hope that others will find them useful for their own use or developing the solution further. You can grab the source from our public Hog Camp mercurial repository.
Hog Camp is an internal Hack Day at hedgehog lab that takes place for 2 days every other month. Our first Hog Camp
in September 2009 was a success (a blog post on this will follow soon) and there has been a fair bit of interest from people who
would like to attend, even though it is internal.
Therefore, we have decided to open up our November Hog Camp to a select list of invitees who can join along in the beer+pizza fuelled
coding sessions and produce some awesome code. If you would like to be invited to it, please enter your details below and we
will let you know if you have made the guest list. Your invitation will contain more details of the format, the dates and miscellaneous
details.
Dan Pink is an author and speaker who despite having worked in politics, has a surprisingly interesting take on managing employees and how the modern workplace should function.
I watched a recent talk of his at TED after being pointed to it by Herb Kim. I would advise anyone who is considering running their own business or has already been running one to watch the talk, which makes a strong fact-based argument for radically re-defining the way we motivate employees at work.
In both his talk at TED and his thought-provoking book A Whole New Mind, Dan talks about right-brain thinking and how creativity is now an essential competitive advantage in the workplace. Like the talk, the book is a must-read for the insight it provides into creativity and how simple it can be to instil it into both your personal and work life.
At hedgehog lab, we have always taken pride in our left-brain strengths and developers with strong logic, reasoning and language skills. Our entire hiring policy and ethos has been surrounded by the fact that we are a company for developers, by developers. Sure there is a lot of creativity and abstract thinking involved in general software development but our work practises and hiring processes were geared towards left-brain focused developers.
We did have processes in place to encourage creativity, like our Lab Days, which were informal internal hack days. Unfortunately, the pressures of every day work and deadlines meant that this process was woefully managed and resulted in very little. In retrospect, this was a necessary but unfortunate path to becoming a sustainable small company.
Meanwhile, in the past year, we turned down around 10 different designers who applied to work at hedgehog lab because I was absolutely convinced that our in-house team had no need for a permanent creative member of staff. Why hire a full-time creative person when we could focus on our core competency[sic] and outsource graphic design and creative work to freelancers and companies skilled at this?
The problem with this was that, although it was good traditional business wisdom, it did not take into account the exponential benefits a creative person could bring to our team and products while changing the monotonous composition of the team. It was becoming clear to us that the advantages of having an in-house designer far outweighed the negatives.
This is where Dan Pink and his theories come into play. To tie in with our recent office move, we took some time off to think about how we can inject some of the creative principles and right-brain culture in hedgehog lab. This essentially culminated in the following new practises that have been brought about at the lab.
Switching to a Results-Only Work Environment (ROWE)
ROWE is an extension of our existing working practises to focus on results and move the focus away from time spent on a particular task. We have always had a liberal working policy at hedgehog lab but we have often been guilty of focusing too much on measuring and evaluating the amount of time spent by individuals in "doing stuff". Although results were still more important than time in the past, a formalised ROWE process gives us better guidelines and tools to measure and motivate employees in the future.
Monthly "Hog Camp"
Hog Camp is essentially our version of the Google 20% time (where each engineer gets to spend 20% of their time working on interesting and non-core projects). Unlike Google however, our growth rate is far slower, which means we could not afford a day a week from employees' time. Hog Camp is a monthly internal 2-day BarCamp where the team gets together every month to hack on interesting ideas and code fuelled by plenty of pizza and beer. Our first Hog Camp is in September and we will posting the results of this soon.
Hiring a designer
We are now actively looking for a creative designer for our team. If you are someone who loves producing beautiful and usable interfaces and "gets design", then please get in touch with us. Alternatively, if you know someone who is looking for a new challenge and is happy working with geeks, let them know about us. We have no specific and rigid criteria as long as you have the right aptitude and principles to fit into hedgehog lab. A creative job application could help too.
No doubt, I will be reporting in a few months what impact these changes have had at hedgehog lab and if there were any negative results.
It has been a very quiet 2 months on the lab blog as we go through a hectic phase of growth and changes at the lab HQ. I wanted to take a minute (or 30) out of our frantic schedule of product development and daily grind to provide a quick update of what's happening at hedgehog lab.
Office Move
When we started hedgehog lab 2 years ago, we had a grand vision of the type of office we would like to work in and the nature of office space that would enable us to get the best out of our employees. Unfortunately, as a bootstrapped company, we had to make compromises with the space due to restrictive costs and company size. In some ways, we just got comfortable with our current office and decided to cram as many people in as possible, so we could focus on the business at hand.
Fortunately, hedgehog lab is going up in the world and both our revenues and employee count has increased steadily in the past year, which meant we needed to re-assess the space we had and look for a larger space that suits us. Anybody who has undertaken an office search knows that this is a painful and drawn out process, and it took nearly 6 months to find our ideal office.
Therefore, I am pleased to announce that the lab will soon be moving to new premises at The Kiln in Hoults Yard in Newcastle. Hoults have some fantastic space with all the right facilities and have a great team to back it up with exceptional service. I would recommend anyone looking for new office space to try them out.
The Aerons have been ordered and the IKEA furniture delivered, so we will be moving our postal address in the coming 3 weeks. Keep an eye out for pictures on our blog of our new office.
New employee
Ever since we launched hedgehog lab, we have been very keen to enter the mobile space and bring our unique blend of enterprise understanding and user experience love to the table. However, our product strategy and existing demands meant that we were never fully able to make mobile products a core strategy other than dabbling in bits and pieces of R&D.
I am please to announce that with our most recent hire, Jonathan Williamson (or Jonny as we call him!), we now have a full-time mobile developer and the making of our dedicated mobile team at hedgehog lab. Jonny will be working on defining our mobile strategy and on a mobile app or two that we will be announcing soon.
Products update
We have been firing on all cylinders in terms of our product development roadmap with massive progress being made on both fixx and solomon. Due to current customer demand, fixx has been prioritised a bit higher to resolve key bugs and implement some exciting new features. We are working hard on fixx 1.9, which is another feature loaded release after 1.8.
The original idea was to stop new feature development at 1.8 and continue with 2.0 but customer demand and the increasing popularity of fixx has meant that we wanted to deliver some key features in the 1.x stream.
Unfortunately, this means delays in getting a beta of solomon out but rest assured that solomon is not vapourware and the heavy interest and demand for this means that, quite honestly, we cannot afford to not release it soon.
As always, keep an eye out on our blog for more updates as soon as we settle into our new office space.
When we released fixx 1.8 a couple of months ago, we were elated to deliver the biggest set of functionality in fixx since launch. With 50+ new features or
enhancements, it was inevitable that the changes would impact some of our customers in a large way.
Unfortunately for us, some of the improvements manifested as critical upgrade issues for a few customers and we would sincerely like to
apologise for this. We should have anticipated and put in additional tests for these but we did not and I would like to apologise to those customers that have had
to postpone their 1.8 upgrade because of these issues.
To be clear, the critical problems only apply to existing customers who upgraded from 1.7 and we have worked hard to resolve these
problems in the past 2 weeks.
As a result, we are releasing fixx 1.8.1 which addresses these critical upgrade issues and some major bugs reported from our 1.8 release. We would
advise all customers (even those on 1.8 already) upgrade to 1.8.1 as soon as possible.
We are no strangers to hacking at stuff here in the lab and we love building useful tools and add-ons using our own APIs. In that long running
tradition, I wanted to announce a little pet project I started a few days ago.
fixx Django Middleware (I know it's original) is the aptly named
middleware app for people who run Django sites/applications. It provides an exception handler in the middleware that allows you to log exceptions
that occur in your Django instance directly to your fixx instance encouraging pro-active problem solving than waiting for visitors to report
bugs in your Django site/app.
The middleware component does required fixx 1.8+ to work with.
You can grab a copy of the code which is licensed under the BSD
license and is free for you to modify.
Why not take a look at some of these other API-enabled tools/add-ons for fixx we are working on and even see if you can contribute?
It was exactly 2 years ago to tomorrow that we moved some basic furniture including broken garden chairs into our first office. If someone had said to me then that we would still be here 2 years on, sailing above the most difficult recession to hit the country in my time, I would definitely have had a good laugh on their account. Yet, I am absolutely delighted to say that hedgehog lab is officially 2 years old now.
In these past 2 years, we have been through some very difficult times and some absolutely delightful moments but the following were the lows and highs that have shaped our company and the team, as they are today.
Lows
Running out of savings and credit cards
When we founded hedgehog lab, Mark (my co-founder) and I were probably the most ill-suited for entrepreneurship. We both had big mortgages, very well paid jobs and very little savings.
Yet, our passion and conviction about the business and what we wanted to do was so strong that we decided to drop everything, risking a lot of money to pursue what was closest to our hearts. We used up every penny of our cash savings and went through a torrential first few months without generating much revenue. We even had to resort to borrowing from credit cards to fund our work with no real guaranteed revenue. It was simply dogged persistence and hard work that pulled us through this.
Letting go of staff
The most painful moment in our short history had to be the moment we had to let go of our first 3 employees in 2008. Facing delays in the release of our first product fixx, little cash in the bank, and the loss of a large consultancy project we were banking on, we reluctantly had to let go of 3 wonderful employees. I am sure every entrepreneur will tell you this but the morning of the day we broke the news to them felt like the gloomiest day we ever had.
I remember how terrible Mark and I felt the rest of the week, and just turning up for work every day was an uphill climb. Yet, we knew that we took the right decision for the business and thanks to quick but painful decision making, the company is far stronger in the long run.
Market Research
We always knew that we were going to build, fixx, our bug tracking system, as our first product. The advice we got from Business Link (a Government-funded start-up support organisation) was to conduct market research and talk to prospective customers about the product. Since market research was a relatively new field to us, and since everybody else seemed to be doing it, we took the bait and set about doing market research.
If you know the bug tracking market, you will find that what we found in our market research was nothing less than a prediction of total doom. However, it always seemed to me that market research was good at comparing features, predicting figures and stats but could never capture the essence of building a "usable" and "simpler" product. We dug our heels in and 2 years later, the evidence points to the fact that we were onto something.
Highs
The highs far outweigh the lows, and this in essence is why we are still passionate about turning up for work every day and have a blast doing what we do. So what were the highs?
Exponential revenue growth
Although it is fairly early to say this, as it stands, we are looking at least 3 digit growth year on year for the first 3 years. We have already made more revenue in the first 3 months of our current financial year than in the entire last financial year, and are looking to triple our revenues in the next 10 months.
Exceptional people
We have had the chance to work with some brilliant people, both in our current team and previous team. It is an absolute pleasure to go to work every day knowing that everyone there comes into work rearing to go and with a lot of passion for what they do. It also helps that they have a great sense of humour.
I wanted to do a longer post on the specific lessons we have learned in business as a young company, but I remember a talk I gave a couple of months ago at a local event that sums up our lessons in business.
I usually do not respond on our blog to articles or blog posts elsewhere, simply because I have nothing useful to say in response or don't have
a strong counter-argument to present. However, the Telegraph's commentary on the
Sun Tech Mission 2009 was too much
bait to resist responding to.
Unlike many of my peers, I am not out to defend the North. The problem I have is with the general slant of the article and the basis behind the opinions drawn in it.
The point that aptly illustrates everything that is wrong about businesses based in London is the following line,
"Plugging yourself in to the London circuit is the best way to generate buzz around your product. More importantly, it gives you the best chance of making the connections you need to investors and other start-ups."
This, fundamentally, is what wrong is with many businesses (especially tech) these days. Since when has business success been measured by how much PR/buzz you could generate or how much investment you could eke out of rich London bankers? The entire article is based on the assumption that to have a successful business, you have to pitch to investors, get them to invest a lot of money, generate lots of buzz around your product, and finally hope Google buys you for a ridiculous amount of money.
There are many reasons to base a business in London and I admit there might be statistically far more successful start-ups in London than in the North of England (I would love to see those stats) but to define success within the narrow scope of investment-led businesses is ignoring the large majority of grassroots, boot-strapped businesses that might never get on the news but contribute a large part to the economy.
Whatever happened to building great products, generating revenue and building sustainable long-term businesses? Are you not classified as a start-up anymore if you don't attend the hundreds of BarCamps or don't get featured on Techcrunch or ReadWriteWeb?
Given the current economic climate, what we need is more "boring" start-ups that can create jobs and pay taxes. Granted that venture-backed start-ups create immense value and wealth if they succeed but the success rate of these start-ups is certainly no more than that of other start-ups.
A lot of the article is based on opinions and comments by entrepreneurs who are biased because they are either based in London or are moving there. The kind of entrepreneurs who, with all due respect, believe that the only kind of tech company to build is the next Facebook, Youtube or Twitter.
(Update:Nick Bell from Quick.tv responds to my above over-generalisation in comments below. It was certainly not aimed at Nick and/or Quick.tv)
The article does make a fair number of valid points like the Government-funded schemes largely administered by people with little background in the tech industry. I also agree that support and advice for technology businesses is weaker than what is available in London. There are issues surrounding the quality of networking and the general ability of tech companies in the region to collaborate. However, none of these seem to be a reason to move to London. If they were, then why not just move to Silicon Valley, because as the article says, if the South were better than the North then by that measure Silicon Valley is far better than the South of England.
Will the real tech media please stand up and provide commentary and reports that reflect the fact there are more ways to do business in technology than generating buzz, building old boys networks and throwing around a lot of cash. The City of London and the financial institutions were symbolic of this and were much taunted examples of the superiority of London as a centre of business. We all know how that ended!
This is a month later than we had planned but I am excited to announce that we have just release fixx 1.8 into the wild. This is our biggest feature
release yet with 63 major issues raised by customers for a while.
Here is what is in store for 1.8,
You can now perform a 1-click import from FogBugz 6.0 and above.
Ability to backup and restore an entire instance of fixx through the Admin interface.
The Rich Text editor has been modified to now support XHTML and support for Textile/Markdown has been removed.
Ability to notify issue assignee when commenting.
Ability to have "private" issues.
More functionality in the API to deal with issues and comments.
I know it has been very quiet around here at the lab, but we have been incredibly busy working on the biggest release yet of
fixx and slaving hard to release a beta of solomon.
However, I did want to take this opportunity to announce firefixx, a Firefox extension for fixx. Currently, all you can do with
firefixx is drag & drop files into the browser to automatically attach them to an issue. As long as you are viewing an issue and have
permissions to upload files, just dragging & dropping a file into the main browser window will automatically upload it.
Although the functionality is basic (no feedback/progress or UI), we have big plans for this extension in the coming months. What's even
better is that firefixx is a BSD licensed project and the source is available on Github if you want to take it and write your own hacks. We
can't promise we will use all of them in the core extension but it's not like us to say no to useful contributions?
I think we have already established the fact that I am not going ga-ga over SaaS and the hype machine which currently surrounds hosted software.
One frequent financial argument I always come across, on-line or off-line, for people choosing hosted software is the superiority of the subscription-based, pay monthly model, as a consumer. And to a large extent, this is an advantage that I cannot brush off easily. However, if we delve into the reasoning behind why people see this as a better model, it becomes apparent that these are exactly the kind of decisions that led to the excessive financial debt that plagues many people in their personal life.
People will gladly pay $19.99 a month, rather than a $149 up-front because the initial cost of the monthly option is nearly 10 times lower. Who can argue with that? If you decide 3 months into your product use that it isn't good enough, just cancel your account and you have only spent around $60. That is still a $90 saving over an up-front option. I am not really making my case here, am I?
Let me present another angle. What if you paid $149 for an up-front, self-hosted software product but it came with a 90 day refund policy? That is a total cost of zero to you.
What if you, for some weird reason, decided to stay with the product and the product offered free upgrades for up to a year? That is a total cost of $149 with your up-front option, while your hosted option comes to $240. What if you decided to use it for 2 years? This is a very realistic usage pattern for most people, where systems are used for years.
"Great! But what about the time and effort you spend installing, configuring and upgrading this self-hosted product." What if the product took an average of 5 minutes to install, configure and 5 minutes every time you upgraded it?
No matter how you look at this hypothetical situation, only 1 option makes financial sense for the person making the purchasing decision. Yet, it comes as no surprise to me that many would take the subscription option, because it allows you to "pay in instalments" despite the high overall cost.
To be clear, there are many domains and scenarios in which the hosted option is the better financial choice. For me, this is any up-front option that costs more than 24 to 30 times (because I expect to use most software on average for 2 years) the monthly subscription cost for the hosted option.
So what has SaaS got to do with the Credit Crunch? Nothing except the fact that the financial reasoning behind both seems very dubious!
I know a few of you have been holding your breath for this one, and we are pretty excited about this release too. Quite strange, considering 1.7 is
actually a bug fix release, rather than a feature-intensive one.
Nevertheless, we are very excited about the massive performance gains 1.7 gives and a reliable API. We have some interesting API-related tools and blog posts in the pipeline, so keep an eye out.
Our next stop is 1.8, which will be our final feature-intensive release for the 1.x branch (everything after that will be bug fix releases). Yes, this does mean that fixx 2.0 is already in development, and boy is it looking good! The biggest feature going into 1.8 will be a more complete API, with all the missing functionality
implemented, and some serious bundled tools/scripts for Source Control Integration and bespoke migration of bug tracking systems.
A recent conversation on a local community forum about a software vendor who required the filling in of a 2 page form just to get in touch raised my irk and reminded me of key marketing errors that ISVs seem to make. I wanted to share these in the hope that budding entrepreneurs avoid these mistakes that can be very frustrating for customers.
Not publishing your contact details
Yes, you can have a Contact form that tries to collect structured data to allow you to respond to queries but not publishing your e-mail, telephone number, or address is a big no when it comes to selling products online.
Other than building trust in the customer that you are not a doubt-able business, it encourages customers to start a dialogue in a manner that they choose and at a time they choose.
Requiring sign-up to download your free/trial product.
To be clear, there are niche sectors and products where it might well be required to capture a lot of customer information before you let them download a product (no examples I am afraid).
However, for most software products and especially in crowded marketplaces, it just doesn't make sense to force customers to go through a lengthy sign-up process and gather their auto-biography to let them download the product.
If the trial does not convince the customer to purchase a product, then I doubt any direct marketing gimmicks will.
Having a blog / news section that doesn't say much.
A blog is a powerful marketing tool, but I see this so often that I had to mention it. They usually fall into 1 of 2 categories,
Press Releases These blogs and news sections are nothing but press releases with a fancy picture added to make it look more personal. They usually talk about how awesome the company is, or how a new client has decided to choose their awesomeness, or how they are doing awesome things.
Don't get me wrong. There is nothing wrong with keeping readers up-to-date with your successes and promoting the good work you are doing. The problem is people will get frustrated with all the self promotion if you have nothing useful to say eventually.
Journal I know of a few companies (whose names I shall not mention), who excruciatingly detail every mundane activity from buying new desks to an employee being off sick. How is this useful to a customer, fan, or prospective employee? All it tells them is that you are dull and have nothing useful to say.
Having a blog but not allowing comments
Note that I am not saying that you should not moderate comments (we moderate all our comments). Moderation is fine as long as you allow some form of feedback and a way for people to engage with you and react to your blog post. Rejecting criticism and allowing only nice comments might sound prudent but people are bound to take their criticism elsewhere, where you have no control over the medium.
Lack of spam prevention on the blog
As a professional company, it reflects very badly if you do not moderate your blog or have spam prevention tools on it. This is a no-brainer given most popular blogging platforms allow this or it is fairly easy to implement in a custom blogging solution.
Our solution to this problem is to moderate all comments, whether it be for spam or inappropriate content. Even regular comments are not approved until someone manually approves it. This means that the quality of the comments and dialogue is fairly good.
Competitive comparisons
The biggest purchasing activity that a customer performs is to compare competing products to help make a decision on which one to purchase. It just seems obvious then that it is a great idea to include a matrix comparing your competitors to your product.
The practical flaw with comparisons is that they are never objective (unless they are on Wikipedia). Do you know anyone that actively lists factual weaknesses against their competitors? Most people I have spoken to say they immediately dismiss comparisons with competing products as they never trust them.
Your effort is better spent in highlighting the benefits of your product and why a customer should consider purchasing your product on it's own merits.
Putting valuable content in inaccessible documents
Lots of companies have excellent case studies and valuable marketing material but in a moment of uninspired genius, they decide to make them available in either PDF format, or worse, as Microsoft Word or Powerpoint files.
There is nothing wrong with a well-designed concise PDF that people can take away to read in their own time. We use them ourselves. The problem is that most of these PDFs were made for print (large sizes and unnecessary graphics) and just dumped in a download-able folder making it tedious for the customer to get information.
So you are a small company or ISV that develops software products. Your company is doing great and sales are increasing but you find that you are spending more and more time doing support and dealing with irate customers. You are developer(s) at heart and find it frustrating to deal with customer service and support. After all, why should you? It is not your core competency. You feel you should focus on what you are best at, coding.
In a moment of genius, it strikes you that if you can outsource accounting/book-keeping and your legal issues, why not outsource your sales and support to a company that specialises in sales & marketing. This would free up all your time to work on some beautiful code. Tip : Do not do it!
Outsourcing your sales and support is one of the worst ideas you can conceive of. Forget about cost-cutting, efficiency and all the apparent benefits you can see. Just don't do it!
Customer service is a competitive advantage
Whether you are a small business or large, customer service is one of your biggest competitive advantages. All the bells and whistles, features and innovation in your product combined are still worth less than delivering exceptional customer service.
Very few companies can get away with poor service and a great product (I would love to hear if you know any). On the other hand, a lot of companies do great with exceptional customer service and mundane products. Zappos sells shoes. But try convincing their customers they are the average shoestore and they will probably disagree.
Customer service is marketing
This is not rocket science. Great customer service generates word of mouth and creates fans. This directly leads to increased sales and recognition. Do you spend lots on PR and advertising? Try cutting that spend and investing in great customer service.
Customer service is employee retention
Great customer service is not just about selling and marketing. It also generates motivation in your team, helps your employees spread the word about how good you are and creates an environment where everybody wants to work.
Customer service is about knowledge
At hedgehog lab, we encourage and sometimes require that our developers deal with support and sales queries. This is because no amount of documentation/manuals/training can give anyone else the deep knowledge of a product that you as the developer have. Someone who is not involved with the company on an intrinsic and daily basis will just not have the knowledge and answers required, resulting in canned responses and delayed support.
Customer service is not rocket science
Despite customer service being a great skill to have, it is not a complicated science and comes naturally to most people. It is about being polite, responsive, giving the right answers, and being emphatic in dealing with problems. Yes, you might need some experience to become good, but there is absolutely no obstacle (other than attitude) to prevent delivering great support.
All of these principles apply whether you are a small or large company. Whether you have specialised support staff or do support yourself depends on your size and business, but for God's sake, do not outsource customer service and support.
I recently got asked by a customer about whether we eat our own dog food in using fixx (which we do) and the conversation veered towards what I think are bug tracking best practices.
A lot of the so-called best practice is just common sense (as it always is) but it is surprising how little they are used. Therefore, I thought I would share what we feel are bug tracking best practices from the view-point of 3 different roles.
For end users
When you report a software bug, it is imperative that you detail how the bug was caused in the first place. This will help the developers in finding the root cause and fixing it.
Never provide a solution unless you are a developer in-charge of the functionality. Leave it to the developer to implement the best solution.
For Developers
Be patient! We all know how frustrating bug reports can be. Try to re-assign the issue back to the reporter and ask for clarification rather than dismissing it.
Don't be defensive. I have certainly been guilty of this. No developer likes being told their code is buggy, but try to verify whether something is a bug or not before you dismiss it.
Try to use filtering, reporting and organisation features in the bug tracker to keep your focus on a specific set of issues.
Do not close issues unless you raised them. The only person who should close an issue is the person who raised the issue and can verify if it is resolved or not.
Try to provide estimates that accurately reflect the effort required for a task.
Added by David in comments - If you are working on an open source project, try to provide a suggested solution (in the form of source code patches) along with the bug report.
For Project Managers
Resist the temptation to keep adding new "fields" and meta data. Remember that the focus of the bug tracking system is not to store boat loads of information but to enable you to get things done and fix issues.
Try to keep the workflow simple. The key is to get an issue from open to closed in the fastest time possible. Complex workflows only serve bureaucracy and encourage procrastination in the process.
Trust your developers and testers to make the right decisions. Do not enforce too much control with complicated permissions and umpteen approval/review processes to get a bug resolved.
Try to keep tasks or issues that are small and achievable. "Develop a visitor management system" is not a feature/task, it is a project (as ludicrous as it may seem, this is a real world example).
Don't go overboard with reports. Project Managers love nothing more than constantly generating reports that all say the same thing with a different presentation.
I would love to hear if any of you have any other tips or best practices that you use in your organisation.
The year was 1999. It was my first year of University and I had a compulsory module titled "Fundamentals of Software Engineering". As a self-taught programmer, who liked to learn things by "hacking" at code, there was nothing I dreaded more than a 40-year old balding professor who was going to preach "methodologies" and talk about some language used in World War I called Ada. Why couldn't we just get on and create some cool Assembly code and hack on those spare micro-processor units?
Turns out that the professor was not that boring after all and methodologies were quite important in the real world. Between the yawn inducing talk of SSADM and boring geometry of UML, we talked about gems like No Silver Bullet, The Mythical Man Month, and other interesting discussions on real-world software delivery.
It was in this module that I learned of the then revolutionary [sic] software development methodology called Iterative Incremental Development. It just made sense! This was the real deal and I was going to conquer the world with an all new way of developing software. And then I got a real job!
The iterative incremental model was primarily championed in those days by the Rational Unified Process, which had more templates and documentation than my entire university course books combined. It was the flavour of the day, and it was meant to solve all our software engineering pains.
Fast forward nearly 10 years and the web is now filled with talk about how agile development will rescue the economy (interesting, Toyota reported their first operating loss in their 71 year history today). Heck, SCRUM is so cool, it is the only software development process where I can call someone pig and still keep a straight face.
Let me make it clear that I (and my company) believe and practise the core principles of Agile Software Development, primarily the iterative incremental development, transparency, and working systems at all stages. I have no problem with promoting and encouraging agile development, however, let's just be clear that this is nothing new. Scrum was mainstream since 2001 and iterative incremental development preceded even that.
Agile Software Development is not about tools, technology or marketing buzzwords. You don't need fancy words like sprint, card walls, or Scrum to practise an agile development process. Agile development is about people and process, and no one has a monopoly on this.
One question we frequently get asked at hedgehog lab is, "Do you offer a hosted version of fixx?", to which my answer always is, "No, and we currently have no plans to do this although this might change eventually."
Just to be clear, when I refer to hosted software it refers exclusively to applications delivered over the web as a service or SaaS like Basecamp, Freshbooks, <fancy Web 2.0 app name here>."
Although I am a huge fan of many a good hosted applications (the 2 mentioned above being great examples), I am not entirely convinced of the apparently superior advantage this model has as opposed to installable software.
The advantages and benefits of the hosted model have been covered almost everywhere else, so I won't get into them. What I would like to cover is what we see as our basis for choosing an installable model and why we feel that hosted software comes with it's own perils.
Cost
An often used "benefit" by those selling hosted software is that it is cheaper in comparison to installable software. This is true in most cases but definitely not universal.
But what about the cost of installing, maintaining and administering your installable software? The problem here lies in the fact that historically, most installable software was designed with little thought given to the pains of those managing the systems. For example, our bug tracking system takes a little under 15 minutes on average to install, set-up and run with the default configuration. The last time I signed up for Salesforce, it took me the better part of an hour to sign-up and configure the system for use.
Essentially the problem here is not whether the software is installed or hosted, but the complexity of the system, out-dated pricing models and the user experience it delivers.
Vendor lock-in
I actually disagree with the base argument against reliability of hosted software, that the data is in-secure or the technical infrastructure is unreliable. The reliability I refer to is the reliance of a business on a hosted software for business critical applications. Could you continue business if they suddenly decided to discontinue the product or went out of business?
The well-covered recent story of Sandy and the mixed responses are a great example of how let down people can feel when something they have come to rely on discontinues. If the application was installed, I am sure many people would feel disappointed too, but at least continue using the functionality that is vital to their everyday use.
Another example is of the excellent and now-defunct Zimki, which was shut down last year.
Lack of choice
The primary lack of choice in hosted software is that you don't have any control over when and what features change. Because the system is common for everyone, you have to live with the least common denominator that tries to cater for everybody.
The biggest problem with hosted software is any lack of real differentiation in the hundreds of web-based project management, CRM, and time tracking clones. The functionality difference between systems is negligible and what really differentiates them is not exclusively to hosted software.
Great support, user-friendliness and listening to customers is not exclusive to just hosted software.
A few years ago, you were one of the elite if you were a hosted service. Today, you are more likely to be in a less crowded market if you are selling installable software that delivers real value.
Having said that, I would not write off hosted software completely given choice available and the ease of use of most systems. I would just advise caution when considering your business model as a supplier and the platforms you choose to use as a consumer.
I am a huge fan of Mozilla Ubiquity and have been using it a lot recently to improve my in-browser productivity. Combined with Quicksilver on the desktop, this creates a powerful suite of productivity tools for power users like me.
I wanted to share an Ubiquity command I now use to search my fixx instance and access issues directly (by just typing the fixx issue number) from any page I am in. Just remember to replace localhost:9000 in the script with the URL of your fixx installation.
EventBox looks like a promising native app for Mac OS X. I love it's Growl integration and for a beta, it delivers a great experience on the desktop bringing together my Twitter and Facebook accounts.
I look forward to seeing more services integrated into this and at $20, it is a real steal.
A day doesn't go by without someone I know asking me "how is business going?", obviously referring to our being a small boot-strapped start-up in the current economic climate. The media is doing a great job of covering the doom-and-gloom of the state of the economy, so I am afraid there isn't much more I can report on that end.
My response to them always is "Hell! Better than ever before." Sure, we are all affected by the economic crisis, and there is no denying that. Venture Capital has dried up and credit is nowhere to be found. Hence, now is the best time to be a boot-strapped technology start-up.
Here is why,
Lack of lavish venture capital and easy credit is a boon. Businesses now have to become cash-flow positive rather than building their strategy on "borrowed" money. Which means, that if you start a company that is cash-flow positive in the current economy, it will have a sound financial infrastructure for the future.
If you have been laid off recently, terrible as it may be, now is a perfect time to pursue that idea or business you always wanted to. You have already faced the worst that could happen and your risk profile is probably lowest at this time. You have nothing to lose and the opportunity cost is low.
If you are in the service business, larger clients are more likely to explore working with smaller companies to be more cost-effective. This doesn't mean you have to be cheap, but as a small/start-up company your overheads will be so low that you can effectively compete with larger businesses. At hedgehog lab, service-based activity has increased 5 fold in the last 2 months, with even FTSE 100 companies considering working with more flexible, smaller businesses.
With your larger competitors cutting costs and trying to reduce their exposure to financial risk (because of larger payroll and costs), you will have decreased competition and a great opportunity to offer value in both products and services. As a small company, you don't need that much revenue or profit to stay afloat, while your larger competitors needs hundreds of thousands just to pay their employees.
If you are in the product business and build business software that makes companies more efficient, saves them time, and saves them money, then you are likely to have more interest from customers. This is especially true if your product is priced affordably for the mid-market. Big-ticket purchases are unlikely to get approved in corporations in the current climate, but small software purchases that fly under corporate purchasing limits are likely to get the nod.
An unfortunate up-side of all the people being laid off is that great employees and co-founders are easier to come by. Not all corporate "cost-cutting policies" are based on merit and you will get to hire great talent for a relatively lower cost with no competition.
Obviously, I am not claiming that it is good to start a business only in an economic downturn, but now is as good as any other time, if not better.
I am pleased to announce the release of fixx 1.5, which is our biggest release yet. The release includes many key bug fixes and improvements along with 2 popular features that have been requested by you.
The new features in 1.5 are,
Brand new time reports for every project (see screenshot below).
Ability to use an existing project as a template for a new project, saving you time re-typing areas, issue types and other meta-data when all your projects are similar.
Although 1.5 does not involve an upgrade to your database, please make sure you back-up your existing fixx installation before you attempt to upgrade.
I was on the panel last week, at a very interesting Think and a Drink event on SaaS and Cloud Computing.
For the purpose of this blog post (and given the gist of the event), let us simplify "cloud computing" to mean "utility computing" (although the purists would argue the cloud is more than just this), where the idea is that you can access, use and discard computing power and resources in the same way you get your gas or electricity, i.e., pay as you use. Also bear with me while I throw in random musings about SaaS in the same breath as cloud computing, since they are so inter-linked.
The core debate of the panel was on the pros and cons of cloud computing, with some having a bi-partisan view on whether it is good or bad for you. However, the undercurrent was on how this is the hot-topic of the day and how everyone could utilise this "revolutionary" advance in technology. Certainly, the recent marketing overdrive by giants like Google, Amazon, and IBM would have you believe that (Random alphabet here)aaS is the future of computing.
Now, I am not nearly as old to say this with any authority, but wasn't this exactly what mainframes offered in the old days? Sure, the Internet makes this cloud a lot more accessible, and huge compared to primitive mainframe deployments, but the concepts of time-sharing, using processor cycles and dumbed down terminals are certainly not new. In fact, the whole desktop/personal computer market came to be because people were dis-satisfied with the restrictive nature of using software that was under a centralised regime.
The real challenge for people in decision-making positions in terms of organisational infrastructure is not to take the extreme viewpoint but to judge the necessity for cloud computing and it's use on a case-by-case basis.
In summary, I think the following key points were made by the panel,
There was overall consensus that "cloud computing" was too often being used as buzzword to cover a lot of scenarios and that we have all been using SaaS from the days of Hotmail and Salesforce, well before Web 2.0 made it trendy.
SaaS and Cloud Computing deliver real value to younger, smaller and riskier start-ups by allowing them to create and run an infrastructure that can compete with larger competitors. It was agreed that larger enterprises would rarely see the benefits of increased adoption.
The main arguments for SaaS (especially) was that there is a lower barrier to entry and you don't need an "IT Department" to deploy and run software that is critical to your business. I personally see this as being a problem with traditional "deployed" software, with it's lack of user friendliness, rather than a real advantage of SaaS.
Salesforce became the dominant player in the CRM market not because it was hosted, but because it offered a painless and user-friendly alternative to the consultingware offered by competing offerings like Siebel and SAP.
There was also a general consensus that SaaS and cloud computing generally cost more in the longer run due to the popular subscription model and the need for people providing hosted services to earn recurring revenue.
One argument I do disagree with in the whole hosted vs installed debate, is that systems you own and run are somehow inherently more secure and reliable. The biggest myth when it comes to the SaaS debate in the enterprise is the concern over data security in hosted systems. Given that SaaS providers cater to economies of scale, their reliability and data security will more likely be better than most in-house infrastructure can come up with.
Flexibility is a huge problem when it comes to hosted software. Again, economies of scale dictate that software delivered using the SaaS model is mostly homogenous, which means you have little or limited choice when it comes to functionality (Facebook re-design anyone?)
A great practical application of SaaS and Cloud Computing infrastructure is to outsource non-core and non-critical operations to these systems. For example, at hedgehog lab, we make heavy use of the cloud to deploy bandwidth intensive downloads (Amazon S3) and we are experimenting with using Amazon EC2 to provide us with a wealth of virtual machines to run our integration and test environments.
However, it was very clear that a lot of enterprises still have real concerns about basing their business model and/or their core operations on a SaaS or cloud computing provider.
I have no doubt that as hardware becomes cheaper and skilled resources become dearer, more people will opt to move everything from non-critical to core operations into the cloud, and that SaaS adoption will increase gradually.
However, let us not lose sight of the reality of the software industry as it stands. Desktop and installed software still outsells hosted software (I would love to know the stats if anyone has them) and SaaS/Cloud Computing is no silver bullet.
Just came across this excellent resource of miscellaneous Java notes. Very useful if you are learning Java or just need something for quick reference. Java Programming Notes.
I am a contributor and avid reader of the Business of Software forums. For those who are not aware, it is an excellent resource for small and micro businesses in the software sector.
However, what piqued my interest this week was a post by an anonymous young reader, who was seeking advice on Procrastination and how to get over it. The overarching theme in the discussion seemed to be that a lot of people feel that they are spending an increasingly more amount of time "surfing the web", than getting things done.
Since the early days of the web, random surfing has always been the bane of productivity for many people (I was there in my university days, so I know the feeling). Obviously, there are many contributing factors to why our active time on the web has increased (I am looking at you Facebook), but I cannot help feeling that RSS is probably a bigger slayer of productivity in early adopters and especially the tech-savvy crowd.
Before the semantic-web-loving, standards-touting crowd frown at me in disgust, let me make it clear that "I love RSS!". Without it, I would not have a voice. Neither would I have been able to keep abreast of current events using what is now my "daily newspaper".
Recent data from time management solution Rescuetime indicates that even though e-mail and IM are still the primary bane of productivity, news & blogs are the second worst offenders when it comes to productivity killers. Obviously, this data is skewed towards people who are sensitive about time management, but nevertheless, it shows an increasing addiction in feed subscribers.
How should organisations handle this? How should individuals handle this? Is the targeted-delivery and subscription RSS provides, increasing the information that is delivered to us or decreasing it? I am afraid I only have questions and no answers at this point.
Finally, I must say I am sorry! Not only have I left this post with more questions than answers, I have also just contributed to killing more of your productivity.
fixx 1.4.1 is a patch release that fixes a few critical bugs that could not wait until 1.5. Apologies to all our customers who have had problems with these bugs, but upgrading to 1.4.1 should resolve these issues.
From this month on, we have decided to do a frequent (at least monthly) summary post highlighting key updates for our products
fixx
The big news for fixx this month is the 1.4 release, which comes with a new iPhone interface and updated permissions for projects.
The fixx documentation has been updated to include guidance on using MySQL as a database backend to your fixx installation. We will be adding more databases to the official documentation soon.
solomon
solomon development has been coming along great and we are almost ready to close out our alpha stage to prepare for a closed private beta. Ensure you sign-up for the beta if you want to get your hands on solomon early. Meanwhile, below are a few screenshots of solomon as it is currently.
Apologies to everyone as this is one week later than we originally planned to release, but we had some final minute show-stoppers that we had to resolve for 1.4.
The highlights of this release are,
The ability to restrict users to certain projects a.k.a Private projects. To do this, you need to mark a project as restricted and explicitly add users to that project.
Key bug fixes to the client and public interfaces.
Since 1.4 involves a significant upgrade to your database, please make sure you back-up your existing fixx installation before you attempt to upgrade.
With fixx 1.4 just around the corner, I wanted to post a sneak preview of our new iPhone interface that we are introducing in fixx.
The initial iPhone interface focuses on 4 core functionality elements. You cannot do everything through the iPhone interface and we wanted to ensure that the features available suited the most common workflow scenarios when using a mobile device.
It is worth noting that this is only the first iteration of iPhone functionality to go into fixx, and future versions will be including additional functionality based on what our customers want. Head over to our forums to request an iPhone feature for fixx.
These are the core features of the iPhone interface in 1.4,
Quick access to view activity and issues relevant to you (using your saved filters).
Last Friday, both Mark Forster and I braved the (short) queue at our local O2 store to grab our new iPhone 3Gs.
I need to make it obvious now that I am an Apple fanboy. Given that I am impressed by everything Apple, I was pretty excited to grab hold of the iPhone 3G, especially for the ability to get to the App Store and download some applications.
The web is already abuzz with iPhone 3G reviews and opinion, so let's skip over that for a minute and concentrate on the new SDK and the applications.
There is absolutely no doubt that the SDK was a step forward and a chance for the iPhone community to develop interesting applications. However, after a week of trying out some popular applications, I must say that I am pretty disappointed with almost every one of them. This is down to 2 factors.
Quality
With the exception of Super Monkey Ball, every single application I have on the iPhone either fails to work (Last.fm, Twitterific), is very slow (Facebook), or is poorly designed (NetNewsWire).
I agree that this has more to do with the developers than anything Apple and I agree that this will get better as time goes by.
Suitability
The bigger issue I have with a lot of the applications is the suitability. Do we really need 10 more native iPhone apps for a To-Do list? Do we really need native iPhone interface to Facebook (I get the point about location-aware data but it really doesn't matter when it comes to Facebook)?
In fact, the best app I have come across on my iPhone (ok! It does still have some quirks), is Google Reader for the iPhone and it is a web application.
There are valid cases for using a native iPhone application, when you need access to native iPhone functionality, but let's not jump on the band-wagon and build iPhone apps just because we can and because it's cool.
This is precisely the reason (now we get to the interesting bit), our new iPhone interface to fixx will be entirely web-based, delivered from your fixx installation.
While we are working on this iPhone interface for fixx, we would love your ideas on what you would like to see in this interface in the long term.
fixx 1.3 is out! This release includes key bug fixes and some general improvements to the tagging system and searching for tags. Also look out for the cool OpenSearch feature for those of you with IE7 and Firefox.
While this comes as no surprise, I am still baffled at the lengths people will go to squeeze another hour into their working schedule. I am personally no stranger to working long hours, mostly because I enjoy doing so. However, I certainly don't believe that working longer = greater productivity.
The reality is that probably 70% - 75% of your working time is probably wasted in trivial non-productive tasks like gossip, reading the news (or feeds if you are a geek), fighting over who makes the coffee, and if you are really unlucky, in boring marathon meetings that suck the life out of you and never end with any real decisions.
If you are a developer or an entrepreneur in software, the best thing you can do is "work less but work smarter".
Why not try working for only 4 or 5 hours in the day but focus that time entirely on the task(s) at hand. So whether you are writing code, content for your new site or designing the next home-page, give it 100% dedication with short breaks to keep you fresh.
This means you still get time in the day to do the things that interest you, like reading your feeds, catching up on e-mails/calls and any gossip around your workplace.
Turn off your instant messaging software or at-least make it obvious you are busy. When was the last time you had an important conversation on IM?
I know that IM has become an important communication medium at work, so if you have to use it, make it obvious to colleagues when to use it.
Turn off your e-mail notifications (unless you are in a job where all you do is respond to e-mail). Again, it is unlikely that most e-mail you get is urgent enough to warrant an immediate response. Using the phone for matters of urgency is definitely a quicker and less time-consuming way to communicate.
Spend money on tools to boost your productivity. Open Source (as in free and open source) software is great but unless it is one of those rare systems that is magic, your time is better spent focusing on your business, whether that be writing more code for your product, or your clients.
Whether you have a work-life balance is your choice but the fact is, in the software business (and probably many other fields), the longer you work, the less productive you are.
Let's stop propagating this myth of longer hours and corrupting the next generation of budding entrepreneurs!
We are all about open standards here at the lab and have always taken pride in implementing little standards-based improvements that make your life and job better while using fixx (ex. OpenID, Microformats etc.).
fixx is now OpenSearch enabled and the feature will be available from 1.3, which is due for release soon. I committed a patch last night that brings OpenSearch auto-discovery to your Firefox and IE7 browsers (and any other browser that supports OpenSearch).
When you navigate to your fixx installation, you should see the search icon in your browser search box turn blue and you should see an action to add fixx to your search engine list. You can then use your browser search box to directly navigate to fixx issues, by typing their issue number, or search for issues in fixx, even when you are browsing another site.
Note that the title of the search engine will be the same as the title of your fixx installation (so it might and probably will be different to what is in the screenshot).
Fluid is a SSB that allows you to wrap your frequently used web applications and sites in it's own browser and activate them as individual applications.
This means you get a separate application for your fixx installation that you can launch from your Applications folder (or using Quicksilver) and use the fixx icon for your application and have it appear in your dock.
Here are 2 high res logos for our products that you can use to your heart's content in your Fluid applications.
I am pleased to announce that fixx, our bug tracking system, has been finally released to the general public.
In keeping with our ideology of simple licensing structures, we have 2 different paid-for licenses available; a Commercial license that allows unlimited users and unlimited projects per instance of fixx, at $799, and an Academic license that is just a Commercial license for academic organisations, at $399.
As stated before, fixx is free to download and use for a single user, under the default Single User license. Try it out.
I would also like to thank everyone who participated in the beta program and provided their valuable feedback to help shape the first release of fixx.
We have more exciting updates to come, and an excellent road-map, so make sure you keep an eye on our blog.
As we rapidly approach the release of fixx, our bug tracking solution (I have heard hushed voices in the Labplex that this might be as soon as Monday), I wanted to take the opportunity to announce the development of our next product.
solomon is a web-based contact manager and simplified CRM solution for small and medium businesses, who want to break free of Neolithic desktop solutions that don't play well with information sharing. It will be a web application you can run on your own hardware, like fixx.
solomon is still brewing at this stage but you are welcome to take a peek and sign-up to be notified when the beta goes out.
Before someone starts the "clone wars", solomon is indeed inspired by Highrise from 37Signals. However, we plan to bring our own unique take to interaction, functionality and purpose to the small business CRM space and fill a gap many existing, over-priced and non-user friendly enterprise web/desktop products have left.
A year or so ago, I met with a then-potential client, who we pitched our software development process to. I went through our usual routine of explaining the various techniques and methods involved, when the client stopped me on 1 specific slide.
"Requirements workshops? Prototype? User Experience?", he said. "Frankly, I am not sure we can justify the spend on that. We are fairly confident of what we need!" With that, he pushed a well-bound booklet called "System Requirements Specification", which some poor analyst had spent months preparing in an isolated cubicle.
Usability or User Experience (or whatever else you choose to call it), is a fledgling concept (in the larger field of Human Computer Interaction), that is all too often considered a "cost" on software projects. Things are certainly changing, with trend-setters like Google and Apple championing both the practical and aesthetic aspects of usability. However, there is still a distinct problem in how organisations (especially in the software industry) deal with usability.
Organisations that have a high focus on usability separate this function away from the core development team, usually employing people in specialist usability roles or worse, an isolated department. There are, of course, great advantages to having specialists in usability and user experience (as with any other discipline), but the problem lies in most developers taking the "not our problem" stance.
Although advanced usability skills require specialist learning and experience, there is no excuse for developers to not be familiar with basic usability concepts and apply them in their every-day role. The expansive literature that is available on usability makes it a breeze even for a novice to learn the basics.
At hedgehog lab, we expect every developer to be involved in the usability process, both at a design and implementation stage. We have no secret-sauce for training them. Just an open-mind, a constant thirst to learn, and some great usability books like the following,
It is high-time that software developers listed usability and user experience design as a key-skill in their arsenal. Let's face it; very soon "usable" will cease to be a benefit or a USP and become the norm, and those software developers who do not embrace this concept will be left behind.
In my last post, I talked about the ethics and principles behind the creation of hedgehog lab. Interestingly, a year after they were formulated, the principles still stand and continue to be applied in our day-to-day operations.
I wanted to discuss the other side of the coin, which are usually "company policies" (or rules or regulations or call them whatever).
It is a given that to operate under the legal structure of a "company", there is some need of guidance and a framework of understanding between people in the company. I suspect this was the reason company policies and rules were conceived. Otherwise, let's face it; you are running a loosely held-together anarchy.
The problem with this, is that, after years of employment law and employer-employee tensions, company policies have grown to a stage where they are either impractical, irrelevant, or sometimes, plain stupid.
We can all identify working in companies where we constantly question the basis of rules and regulations. It is a pity, that it is hard to find an employee these days who does not disagree with some policy that is established by their employer.
At hedgehog lab, we do have policies. However, these policies are not set in isolation by any one person. They are a collective decision taken by the entire team (with one of us co-founders making the final vote, if collective agreement cannot be reached). Moreover, we ensure that these policies are reviewed collectively by everyone and every team member has an indisputable right to question every policy we make.
Policies that worked for us and continue doing so.
Working from home
I discussed our working from home policy in detail in previous posts. This has been an overall success for us, in the fact that we have seen no significant problems with productivity compared to companies where you are forced to "go to work".
The difference here is that, unlike some companies, we are not a remote team (and never will be). Our team enjoy human contact and the collaborative benefits of working together far too much to re-sign ourselves to working from our couch.
Developers are both the front-line and back-office staff
This one splits popular opinion, but we are strong believers that the best way to deliver both exceptional products and service, is to involve developers at both the front-line and back-office operations.
The risk here is that most developers are either not very interested in dealing with customers, or do not have the right skills to pull off customer service and sometimes, sales. Our approach to this has been liberal, where we have left the choice to the person as to whether they want to be involved or not. Luckily for us, everyone in our team has been quite enthusiastic about this.
I believe that with the right amount of support and motivation, you can turn the opinion of the most stubborn developer to get involved in customer-facing operations.
Training
The problem with running a software company that builds products, is that you tend to not have time for doing much else. With milestones to hit, features to plan and bugs to fix, there is very little time and justification for training. It is far worse if you are a service-based company.
We have made it a policy now to encourage training actively, as opposed to leaving developers to "learn in their own time". Using your "lunch break" and "spare time", for training is so 1890s! Our training policy revolves around fully-paid conference attendances, free books and our own lab days, which encourage active discussion and learning of new concepts and technologies.
Policies that didn't work so well (even we get it wrong sometimes!)
Official job titles
When we started hedgehog lab, we wasted something in the magnitude of a whole man-week, trying to come up with the structure of the company. This was when we had 2 people in the company! We deliberated (no really!) a lot on what roles we would have and what titles we would use for future hires.
This week long analysis produced gems like "Director, Technology & Products" and "Developer, Technology & Products" (I'll buy you a chocolate brownie if you have a clue what those roles mean). Suffice to say, we went down a lot of points on the cool-factor with our newest hire, Rey.
Last week, we abolished these job titles and gave the opportunity for everyone to define their own job title, that fits in with what they feel represents their role and job description. Look out for the Code Ninjas!
Business cards
As part of our week-long "formation strategy" (eat that Sun Tzu!), another stupid-genius idea we came up with (to be honest, I have to take the sole responsibility for this), was to have business cards for every employee and make sure they use them when they meet new people. Needless to say, not many of us (the single ones) were getting any dates as a direct result of this!
Ok, maybe it wasn't that bad, but don't even get me started on how stupid and total waste of time this idea was. This policy was quickly abolished, with the business cards being limited to me, for my sins of coming up with the idea (and because I am the Managing Director, I guess)!
We would love to hear about any policies that you have come across, at your present or previous employer, that you either dis-agreed with or were plain stupid/funny.
In the next post in this series, Mark Forster (co-founder of hedgehog lab), will be talking about his personal experience as a developer starting a software company and reflect on the year that was.
A year ago, on 21 May 2007, Mark Forster and I co-founded hedgehog lab. After years of frustration working in full-time jobs that never seemed to fulfil our expectations, we decided that there was a great opportunity to build a developer-friendly company in the North East of England.
In retrospect, it was both the toughest and most fulfilling decision we ever made. Toughest because both of us hardly fit into the popular profile of software start-up founders of our time. When we started hedgehog lab, both of us were well past 25 and had considerable financial risk. Yet, nothing was more clearer in our minds than the single minded determination to create a company that lived up both to it's values and delivered the financial results to be sustainable.
In this series of posts on our anniversary, I wanted to talk about some of the key issues that affected both the founding of hedgehog lab and the journey through the past year. This one covers founding principles.
In an age when most start-ups are founded with the single-minded goal of "making lots of money", often at the expense of both employees and customers, we had a very value and principle focused approach to how we wanted to run hedgehog lab.
In no particular order, the following were the founding principles of hedgehog lab,
Treat your employees right. In turn, they will treat your customers better.
This is so obvious and simple, that it amazes me to see so many companies not follow it. It is blindingly obvious to me that if you want great customer service (in the all-encompassing meaning of the term), you have to start by treating your employees right.
Why is it that "employee loyalty" is much taunted in HR circles, but "employer loyalty" is a rarely used word? An employer-employee relationship is a 2-way relationship, much like a customer-supplier relationship. Yet, companies pay far less attention and effort to maintaining the latter. Given the current supply and demand in the software market, it is high time employers started listening to their people. I understand the irony in my criticism, as I am an employer and an employee. My point still stands!
Have conversations with your customers.
Most companies have only 2 types of interactions with their customers, sales and support. There is nothing wrong with that, but to be a genuinely customer-focused company, you need to engage with them everyday. Listening to your customers is not enough. Talking to your customers is not enough.
We try to reach out to our customers in everything we do. Whether it be a new company policy, the re-design of our website, or ideas for a new product, we engage with customers to gain their feedback and if necessary, make the changes that aligns us better with their needs.
Turn your customers into fans.
Having customers is not enough for us. We want to turn them into fans by appealing to not just their needs but their perceptions of what a great company should be like.
You might think that this is a bit lofty for a company that produces business software. After all, only consumer companies with cool products can turn customers into raving fans. You might just be wrong.
Eat your own dog food
This is mostly used as a promotional strategy by product companies to prove that their product is "good enough". However, at hedgehog lab, this is our primary strategy when developing a new product and is the overarching principle around both product and feature design. We would never develop anything that we would not use as a company or endorse otherwise.
It has been a while in the making, but I am glad to announce the beta release of fixx to the general public.
To the dismay of many of our followers, we have been rather tight-lipped about fixx until now. No doubt, I will be following up with a more detailed post on how fixx came to be, our product development process, the decisions made and lessons learned. For now, we have a sneak peek at the initial features in fixx version 1.0 and a public beta for those who prefer getting their hands dirty.
We are still looking for more beta testers and general feedback or comments are welcome in our people-powered customer forums.
As strongsupporters of open standards and grass-roots community efforts on the web, we at hedgehog lab have always taken pride in helping further the adoption of both.
However, there has always been a feeling lurking at the back of our minds that a lot of this felt like lip-service and that we could do more to lead by example.
Therefore, I am pleased to announce that after a month of development, fixx supports a key set of open standards. This was a tough decision on our end, as it meant that we had to delay the launch of fixx by more time than we intended to.
Open ID
In our experience, Open ID uptake in the enterprise has been slow. The primary reason for this is potentially that many internal users are locked into either a Single Sign-on (SSO) or LDAP solution, as enterprise administrators generally tend to distrust authentication schemes that they have no control over. This is OK if your issue tracker is a closed, private system.
However, when your issue tracker is open to your customers (which it should), or you are an open source project that would like to encourage people to contribute, supporting Open ID ensures that they can authenticate painlessly without having to remember another set of authentication details.
Microformats
fixx currently supports hCard to represent user and profile information. fixx also supports various elemental microformats for content.
We still have a long way in making fixx completely microformats-enabled as we look at incorporating XFN, hCalendar, and xFolk in the future and looking at how we could use some of the more obscure microformats in a web application scenario.
Data Portability
Data-centric (views that return system data) in fixx support retrieving the view in either XHTML, JSON, or XML format, enabling you to write your own widgets and front-end to retrieving data in fixx.
There is also the ability to export your issues into CSV, Excel or PDF formats to do what you want with it.
In spite of all the standards support for fixx, there are still places where it can do with improvements (and we are working on this in future releases).
REST API
Although fixx currently has a REST interface to add, manage and view your data (in JSON, XML, XHTML), the implementation is incomplete and undocumented. We hope to have a finished implementation and complete documentation for the second release of fixx.
Note to hackers: There is still a lot of REST functionality for you to tinker around with (we know you want to!)
RSS
RSS feeds for key views are planned for the next version of fixx. Given that fixx supports notifications through e-mail and Twitter at this moment, RSS is a lower priority in our feature list.
XMPP
Continuing with the theme of notifications, fixx will support XMPP and various other messaging protocols for notifications sent directly to the desktop.
Finally, apologies for the delay in release to everyone who has signed up to be notified, but we are confident that the work we are putting in will be worth the delay.
If you are a freelancer or small agency designing websites, usability testing the websites you create is a bit of a challenge due to the planning, time and cost involved in setting the tests up. Setting up a good user testing environment and getting your target audience to give you valuable feedback is a tough task and hence it is overlooked.
We had the same problem when we decided to go live with the website. Given that we are a small and agile company, we were not bothered about getting user feedback before we went live as we always envisioned the site to improve incrementally with rapid iterations.
We considered many options for user testing and most seemed far too much effort given our busy period (with the release of fixx coming near) and our limited budget. Therefore, I set out on finding methods that will allow us to get some user feedback without breaking the bank.
Out of all the things we tried (which included pestering our developer friends constantly for feedback), 3 really stood out for us and returned tons of feedback which we are sifting through. I admit that the quality of these tests cannot be on par with setting up a controlled user testing environment and neither am I preaching that these methods are better (no flame wars Information Architects!), but if you have limited resources, reach and budget, I can assure you that these will return better results than by-passing usability testing.
I found usertesting.com while browsing through some posts at the Joel on Software forums and man are we impressed! For less than $19 a user, usertesting.com allows you to conduct highly targeted tests. At the end of the test, you will have access to a flash recording of the user's session (with voice) and a transcript of their summarised feedback. I won't go into a sales pitch for them, as their home page does a good job of this but I really like the idea of how usertesting.com has leveraged crowd-sourcing to deliver what is an interesting and useful service. Needless to say, we are very happy with the results and quality of feedback. If anyone knows of other services like usertesting.com, please feel to post in the comments.
A curious one but based on 2 past experiences, I have found LinkedIn to be a good source of feedback based on target audience. Their "Answers" feature allows you to select specific categories under which to post a question. Again, the quality of feedback we had from there has been pretty good. Although I guess this doesn't classify into the scientific mould of "testing", a lot of the audience was our target market. The cost of this exercise? Nil! I presume this could be said of any other "Answers" service but I am only going by what our experience is.
Friends, colleagues and clients
If you are lucky enough to be in an industry where your target customers are your friends, then getting feedback from them is zero cost. Likewise, colleagues in similar jobs but other companies are very valuable, except if they were your competitors! Finally, the obvious one, if you are lucky enough to have good relationships with you're existing clients, there is no one better to get user feedback from (I know you are going duh! but I have seen many instances where people never talk to their customers other than to bill them or pitch new work!).
Do you have an interesting methodology to conduct user testing that is not obvious and does not cost a lot? We are always looking to improve our processes, so please let us know.
Over the past 6 months, I have interviewed close to 100 plus jobseekers and I have to agree with the core points Seth makes. Most of the resumes I receive are monotonous and you could not tell one apart from another, if it not were for the name at the beginning. Some have cover letters, some do not, but the overriding theme between all of them is common skills, relatively similar experience and a list of hobbies that do not tell me anything about what makes the person exceptional.
There is no surprise then that only 1 of our 3 existing team members actually had to submit a resume to us, which we never read twice. All 3 were hired from our network of influence either because we worked with them previously or because they came highly recommended from people we knew.
As a software company, the best thing you can do is get involved with the community and get to know who the brilliant developers are in your area of expertise. Too often, smaller technology companies get so involved in operations and selling, that they distance themselves from the communities that matter to them. The common excuse revolves around, "We just don't have enough time!" Therefore, recruitment becomes a cumbersome business with the daily drone of skimming through resumes and fighting over fees with your recruitment consultant.
Getting involved with the community means that you get to spot the talented people who have skills that cannot be quantified on paper. I would love to employ a Don Brown or a Gareth Rushgrove, as I am sure many others would. What sets both of them apart is their influence in their respective communities (even ignoring the fact that both of them are really good at what they do) and their involvement with grassroots level open source and standards groups. I doubt either of them will ever need to "apply" for a job.
As a developer, you can boost your chances by getting involved with various open source groups or contributing to the community through conferences, blogs or just plain brilliant code. Sure it will take time and sure it involves a lot of work but at least it will save you the effort of writing one more mundane resume.
Software is overrated! You might think that is a bit rich coming from someone who runs a software company. The problem is that to most people, software is synonymous with the code underlying a system. Sure, writing good code is a tough task but let me assure you that writing code itself isn't all that difficult (software companies create value in more than just code, but that topic is for another day).
Ideas are overrated! I cannot begin to describe the number of times I saw a new product or service (software or otherwise) and thought, "Blimey! They stole my idea."
So if both code and ideas are overrated and hardly ever original (note I say hardly, some ideas and code are original), then why is it that technology companies classify these as "intellectual property"? Why is there so much bickering over who owns what when a clever programmer in his basement can create the next big thing and almost any software system can be cloned without much effort?
When will managers and leaders in technology focused companies realise that their real intellectual property are their people?
“The major problems of our work are not so much technological as sociological in nature.”
Simply put, software companies like to blame technology, law, environment, government and everything else for their problems rather than deal with the real problems of people (employees), customers and management.
What better way to make your failure to run effective projects and deliver on time appear more valid, than blaming "intellectual property" issues and crying foul against competitors?
Here is an idea! Why not invest in a great team, listen to your people, bring in better managers, treat your customers with honesty and transparency, and focus on running effective projects. Then see how much the rest matters!
I was recently trawling through my Google Reader subscriptions and came across a post about workplace experiments, which struck a chord with some of the things we do at hedgehog lab to make it a great place to work for our team.
We don’t call what we do “workplace experiments”, as it is just standard practice for us. I thought it would be good to list out all the unique things that we do to enhance everyone’s jobs here at hedgehog lab. I appreciate (given the heated responses to the 37signals post) that these won’t and can’t apply to everyone, so I am in no way recommending these as best practice (although I have yet to get anything but staunch support from our team on these).
4-day week
One of our founding principles was the 4-day week. With the exception of client demands (as we still do some consulting), we regularly work 4-day weeks. No one is required to come into work on a Friday if they do not want to. The problem we are facing is keeping our team away on a Friday! The reality is, if you create the right environment and give people a goal to work towards to, you will have a tough time keeping them away from work.
Expenses
Although we do not offer everyone a company card, we never say no to anything that someone in the team wants (that is reasonable). Books, software and conferences are paid for by the company as long as we can afford them (see you at @media 2008). This ensures our team gets what they want without spending the time getting them; allowing them to focus on getting on with their jobs.
Working from home & Flexible hours
One of the toughest things you can do as an “employer” is trust your team to get on with their job without constantly looking over their backs. Therefore, most working from home policies for office-based businesses are either half-baked or cosmetic at the best. Not so at hedgehog lab.
Our working from home policy is completely flexible and anyone from our team can work from home at management’s discretion. So whether you are having that brand new laptop delivered home or you need to see a doctor miles away, you can rest assured that it will be stress free.
Similarly, our flexible hours are actually flexible. When most companies use the word “flexible hours” they mean that you can come in an hour later but have to stay back an hour later too! When we say “flexible hours”, we are saying “we appreciate there will be times when you cannot get into work on time or want to leave early and we are fine with that!” There is no need to stay later or come in earlier to “make up the hours”. I have yet to see this being abused at the lab!
Profit sharing
Unfortunately we don’t have a bonus scheme at hedgehog lab as we feel that it depends too much on the whims of the person deciding the bonus and offers no real method of measuring contribution.
At hedgehog lab, we have a flat profit sharing scheme. It works on the basis of setting aside a share of our profits every year and dividing this equally between all team members. No matter what your role, junior or senior, director or developer, you get an equal share of the profit. Of course, there might not be a profit to share but that means no one gets an incentive. We feel this is a great way to reward overall performance of the team and company while ensuring no one feels singled out.
Overtime
Although we frown at overtime for our internal projects, work for clients sometimes dictates that we are forced to ask some of our team to work overtime. We accept this as a by-product of service work but instead of fighting against it, we embrace it by innovating on how people are paid for overtime. Instead of paying overtime rates of 2x or 3x times someone’s hourly rate, we pay them the whole amount that the company makes for that work from the client. You heard that right!
These are just some of things we try and do to make life better for everyone in the team. I would be interested in finding out what works for other people and welcome any debate on our approach.
Intellectual Property or IP, for those who don’t know, is one of those words used by companies that never actually produce anything original but claim domain over everything. Even Wikipedia cannot agree on what it exactly stands for (the article on IP is in dispute). In one of my recent interviews, I (possibly controversially) used the phrase “Vaporware is not Intellectual Property.”
This raised an interesting debate internally about the issue,”At what stage in the production of a software system does it actually become your IP?” I am sure this is a highly debatable issue and I know everyone of us had different ideas of what actually constitutes IP.
One thing we were all in agreement though was that Vaporware or software that is nothing more than an idea, or concept (talked about around a drink at a pub) and a few powerpoint slides is not IP. Please! I have heard too many stories from friends who dreamed about building Facebook in 1995! Tough! You did not and Mark Zuckerberg now has enough money to buy a few houses.
As a company that wants to build the best environment possible for developers to flourish in, we have always encouraged freedom of choice in the tools and technologies they use. Our team currently uses a mix of Ubuntu (Simon), Mac OS X (myself), Windows XP (Mark) and Windows Vista (Ashley) as operating systems. We use these because they are the tools that allow the highest level of productivity for us as individuals (although how anyone can be productive on Vista, I am not sure).
Although the mix of systems causes a bit of trouble when it comes to system administration, the pros outweigh the cons and the productivity boost justifies the little extra time we spend in sys admin time. After all, the aim is to make the developers’ life easier!
Likewise, we all have different views when it comes to programming languages of choice with Python, Java and PHP all holding a special place in our hearts. Given that we have experience in using everything from C to Ruby to C#, this usually works to our advantage on the consulting side of our business, being able to provide any development service that clients require.
However, I was reading an interesting post last week on how standardising programming language choices has helped Google innovate with technology and it got me thinking on the advantages of limiting the choice of programming languages, especially for internal use in product development.
At hedgehog lab, we use 4 primary languages for both product and internal development.
Java
Java has always been our language of choice for product development despite many wise people frowning upon it. No other language polarises people so much as Java these days and no matter whatever the arguments, Java is still big in the enterprise and finding qualified people is relatively easier in today’s ultra competitive developer recruitment market.
And the very fact that makes Java undesirable for many (it is not powerful enough or cool enough), makes it reliable for us to work with and the JVM and open source efforts behind Java make it an obvious choice.. Anyway, I am not here to start another debate on Java vs Others; that we use Java to build our products is a simple fact.
PHP
PHP is by far the most popular web development language that we have come across (every small business we speak to wants to use PHP) and like Java, it is easy to learn and recruit for. The evolution of some good frameworks has allowed us to develop some rapid internal applications and experiment with ideas.
Python
Python is our favourite language by far. It is so simple yet powerful and has an impressive cross platform record. With Django, there is now a compelling case for the use of Python to replace PHP (if not for the fact that every one of us knows PHP so well). Our new web site will be built on a custom CMS derived from the Django framework.
Javascript
Perhaps the most misunderstood programming language ever (I remember having many frustrating arguments with developers who insist it is a scripting language), is used in almost all of our UI code (fancy AJAX anyone?) and will even be making its debut in the back-end in one of our new R&D projects.
Given that the set of these 4 languages allow us to do everything from write parallel systems to sockets based servers to desktop systems, we have now decided to limit our set of programming languages to these. It allows us to build greater expertise in these 4 languages while enabling us to contribute back to these communities without spreading ourselves too thin. Given that Python can do pretty much everything PHP can do, we might even decide to reduce the list to 3.
Does this mean individual developers will be restricted from learning new languages? Absolutely not! Developers at hedgehog lab are always encouraged to learn new tools and technologies and we will constantly re-assess the programming languages to see what fits our purpose at any given moment of time. The same applies for client projects where we will still be working on a delicious cocktail of C#, Ruby and other technologies to fit into a client’s environment.
I will be posting again in 6 months to evaluate how things have progressed with our restricted programming language choice and lessons (if any) we learn.
I have always been a strong supporter of grassroots web standards technologies and the semantic web but it has always been through the back of the crowd. When we started hedgehog lab, one of our primary aims was to be a vehicle to promote good practice and the great community around the web and software in general. The best way to do that was to sponsor community events surrounding these topics, but mostweb-related events come with a hefty dent in the wallet when it comes to sponsorship rates.
Therefore, it was refreshing to see that the first Semantic Camp, being organised by none other than Tom Morris, had a flexible sponsorship opportunity to contribute as much or as little as we wanted. As strong proponents of standards and a company filled with geeks who are fascinated about the future of the Semantic Web, we could not resist the chance to be a sponsor.
Although our contribution is trivial compared to some of the other sponsors of the event, we are hoping this will become a stepping stone to lay the foundation for hedgehog lab supporting more events like BarCamp NorthEast (hint to organisers!) and other major web-related events.
Unfortunately, none of us were quick enough to grab a ticket to the event but I am sure we will be turning up to many that will follow the success of this. To those who are going, “Get building the Semantic Web!”
In a follow-up to my last 2 posts about the issues I see facing recruiting developers these days, I came across an interesting post by Mike Cannon-Brookes who is the co-founder and CEO of Atlassian.
Atlassian is a company I admire a lot and hedgehog lab is in part, shaped on many core concepts that Atlassian is built on (ignoring the irony that our core product is a bug tracking system like the legendary JIRA; although I am sure Atlassian PR will be quick to mention that Confluence is their core product now given the meteoric rise in it’s adoption).
What is surprising is that little has changed since Mike’s original post in 2005 and the issues seem to reflect our findings on developer CVs and interviews, a whole 2 years after his post.
Last month, I talked about some of the key issues we identified in the way developers write their CV (especially in relation to applying for a job at hedgehog lab). We take our recruitment process very seriously and it is no surprise that we dedicate up to 15% to 20% of our time in trying to find the best developers we can (for a start-up).
Some have said that we were too harsh for not giving some of the CVs a chance, simply because they were in the format. However, when you spend as much time as we do in finding the right people, it is just not excusable to set our standards any lower. What is more astonishing is that even after our lengthy blog post, we still get people sending us CVs with all the problems described.
Continuing our experiences, I want to discuss our Interview process and things we observed during the interviews. So as not to single out any one person, the issues are generalised but these are based on real cases.
Strictly speaking, we don’t do “Interviews” at hedgehog lab. They are way too formal for our liking and the very mention of the word kills any spontaneity in applicants. In today’s corporate world, interviews are like being thrown into a lion’s den where applicants feel like they are entering “enemy territory” and have to constantly defend themselves against the inevitable grilling and “why are you wasting my time?” glares.
We aim for our interviews to be more of a discussion, debate and conversation between equals. There is no judge and there is no criminal who has to plead their case. Make no mistake about who is evaluating who, but the scrutiny only comes after we have finished the interview, where we can make a formal assessment of how we score the interviewee. Yes there are questions. However, they are meant to simulate conversation and not put the interviewee “under the spot”.
Therefore, without much ado, the following are what we observed as key issues during our interviews,
Be familiar with what you say on your CV.
This is obvious but it is still very surprising how many people put things on their CV that they know nothing about. This is not just related to skills but past experience, jobs and hobbies. If you list something on your CV (whether that be C++, public speaking, sky diving or crab fishing), you have to make sure you can back it up when the interviewer obviously knows more about the subject than you do.
Be passionate about what you do.
One of our official policies is to encourage a 4 day working week so that people can pursue personal projects and interests on a Friday akin to the Google 20%. As part of our interview process, a standard question (hint to potential applicants) is to ask developers what they would use the 20% of their time on. This helps us gauge their passion for their subject and where their interests lie. It is irrelevant what the project is; whether it be researching bio-fuel or writing the next Javascript application platform. What is relevant is how passionate the applicant is in relation to the career they have chosen. Most good developers will usually have a long list of personal projects they always wanted to pursue because they enjoy what they do and want to solve technological problems.
Don’t guess.
This one is obvious but a lot of the questions we ask at an interview have nothing to do with testing your knowledge. They are meant to test your response and aptitude. A good witty response is great (a sense of humour is always a positive) but if you try to guess the answer and mumble, it only proves that you are trying too hard.
Be concise.
This is not applicable every time but I have been in far too many interviews in which a one line answer is stretched out to a 5 minute monologue with ifs and buts and “on the other hands”s. Try and answer the question directly and to the point. The interviewer will appreciate that when he has had 7 interviews on the go and just cannot bear to hear the confessions of another geek.
Do your research.
Job hunting books, blogs and articles have been preaching this for eons but it is still shocking how many people do not do any research on the company they want to spent the next few years of their life in. Out of all the applicants we interviewed, only 2 made the effort to thoroughly research both our company and the interviewers. There is absolutely no excuse for this given Google has made all the information you need available at your fingertips. Try it.
Ask questions.
A definite way to let the interviewer know you are not really interested in their job is by not asking any questions. Like research, if you are serious about joining a company and wanted to spend (potentially) the rest of your life in it, you have to ask questions to make sure it is a right fit for you. Let the interviewer sell the company to you.
It is old news that we at hedgehog lab are on the lookout for great developers to support the growth we are experiencing. It is also old news that recruitment is probably the toughest challenge facing any company.
This series of posts is intended to be an insight into our recruitment process (specifically the pains) and some tips to developers who want to make their prospective employers go “wow”!
Part 1 (this post) covers the humble CV and the common mistakes that we find developers make in writing and sending them out.
Sending your CV in Word or PDF format when our ads specifically mention the format of CV we would like (plain text, hResume or LinkedIn profile). This is a classic case of the “serial applicant” who has not made the effort to read the job ad and decided to apply when they saw the word “developer” in the ad.
Having a one line or no covering note. Just because you are sending your CV in e-mail does not mean that you do not need to write a covering letter (or note). Where there is a covering note, “Please find my CV attached” just does not cut it. Show some enthusiasm for the role and take the effort to summarise your CV for the particular job. If not, at least have a generic covering note which will seem a lot better than a blank email.
Having a covering letter which targets a role that has nothing to do with the job advertised. This sounds ridiculous but we actually received 3 applications from people who were looking for a tech support role, 1 from a sales manager and 1 from a real-time embedded systems developer. All this when they clearly responded to a job that said “web developer”. Even when the application is speculative, it indicates that you have not done your research on our company and you do not have a clue what we do.
How about the CVs that we did read but decided to not take it further?
Having a generic CV with a lot of noise irrelevant to the role. This is the biggest problem with a majority of the CVs we receive (even people we decide to interview are guilty of this). Please take the time to customise your CV for every role you apply for. Not doing so will only make it easier for the employer to mark you as a “serial applicant”. Your CV is the best sales pitch you can make and if you cannot spend more than 5 minutes tailoring it for a role, then it is not worth wasting either of our time.
Putting your list of hobbies/interests/fetishes on the CV (Note: This point is debatable as some employers prefer it. We do not!). I am sorry but we are absolutely not interested in your Karate skills or white water rafting in the weekend at this stage of your application. We expect all of our candidates to be interesting and if you really do have some unique interests, you can be sure we will talk about them in an interview.
Listing every programming language, operating system, database and desktop tool you ever heard of. We are not testing your general knowledge here and are not in the least bit interested how many programming languages you can name. What we are really interested in is the actual skills you gained and used in your previous roles.
Listing every job you have had which has no relevance to the role. It might be cute that you were a lifeguard at your local pool 10 years ago but trust me that it has no bearing on how good you are as a developer. Try and keep your job history relevant to the role. Where your experience is limited, try and focus on the company and year you worked there rather than the role, if the job has no relevant skills.
Although some of these might seem a bit far-fetched, these are real samples of the kind of CVs that a majority of developers write. One could argue that CVs are not really that important because the really good developers do not need a CV. Unless you happen to be in the 1% of really good developers, you have to sell yourself to prospective employers.
In the next part of this series, I will use more samples from our recruitment to talk about the Interview process and where we think developers get it wrong and finally wrap it up with a few general tips (the dos) and a healthy dose of links to essential material for any developer that is job hunting.
(Disclaimer: Please note that there will always be exceptions to every case I have presented and I completely accept there is no one right way of doing things. The methods and tips apply only to our recruitment at hedgehog lab and might not be applicable to other employers.)
As a software company without any external investment and focused on organically growing at this moment, hedgehog lab faces the constant dilemma of balancing revenue with driving innovation and the development of our products. Although we like to think of ourselves as a “product company”, all our current revenue stems from service work on client projects. The need to deliver on client projects while catering time for our in-house products creates a lot of pressure on the schedule available for our products. This is apparently not bad, as many good software products were created with the same constraints. However, the key difference is that we are a start-up that needs nurturing and has high cash demands.
Given these constraints, it is no surprise that getting our product delivery schedule right has been a painful learning process. We have had to constantly revise deadlines, reduce scope and re-visit our estimates. There is nothing wrong with our estimates; we usually get these spot on in client projects. However, the demands of client work means that scheduled product tasks get postponed indefinitely and without working over-time (which is evil), there is just not the possibility to squeeze a set of tasks into a time period. The result of all this is that we were never able to accurately predict our product milestones and the elusive launch date.
In light of this, the article by Joel Spolsky (our un-official mentor) on evidence based scheduling comes as a breath of fresh air. Being able to estimate an approximate release date based on evidence is not a new thing. In fact, it is common sense. What makes this method the crown jewel in scheduling is the fact that it combines facts with a clever algorithm and probability theory to deliver some interesting probabilities of when you can expect to deliver a version of your software. The coolest feature of this (in Fogbugz) has to be the slider that allows you to predict a date by selecting the priority of the features you want to ship. It just makes sense.
Although EBS (Evidence Based Scheduling) has been built into Fogbugz, you don’t necessarily need Fogbugz to implement this. The method is relatively easy to even implement on paper and I presume would be pretty accurate even if you do not take the complex algorithm and factors like velocity into account.
This is something we will be trying at hedgehog lab (we might even customise it to suit our approach) and who knows, it might even turn up in fixx in the future.
One of the great things about Rails is the ability to write and use plugins, which allow the abstraction of repeated code and re-use of code that other people have written.
Therefore, when we found ourselves writing repetitive code to add tasks to various objects (like people, projects etc.) in exxitplan (our latest product), I decided to abstract all of that into a plugin called acts_as_taskable. It is a blatant rip-off of the excellent acts_as_* plugins that come before it (in fact, we just did a find + replace to come up with this plugin), so people should be familiar with it.
A while ago, on recommendation of a friend, I decided to try out Pingdom. It is, in essence, a monitoring tool that is actually well executed. The plethora of features are impressive and their client list is impressive.
Naturally, I decided to sign up for the generous free trial. We tried it out for a while and decided it wasn’t exactly for us. We don’t run anything that was mission critical and we felt we had no need to move to a paid account (even though it was quite affordable). However, we are soon to release a new web-based product, where uptime was a critical issue and I was contemplating whether I should move to the paid Pingdom plan in the next month.
That is, until I received their “your trial has ended e-mail”.
Your Pingdom trial account has been terminated
Hi Sarat Pediredla,
Your Pingdom trial account has been terminated. You can no longer log in to the Pingdom control panel, upgrade your account, or view any of your reports.
Thank you for your time with Pingdom.
Please don’t hesitate to contact us at xxxxxx@pingdom.com if you have any questions.
Best regards,
The Pingdom Team
www.pingdom.com
I don’t claim to be a copywriter and neither am I going to criticise the tone of the e-mail (which is evident). However, I will say that it is a pity that such a good service should be marred by someone’s haste in writing these all-important e-mails. What could have been used as a great retention opportunity has been squandered by the use of some pretty harsh words like “terminated” (who except Arnold Schwarzenegger can make that sound cool?) and “you can no longer log in”.
Instead, why not offer customers an incentive to join or allow them to log-in and export or retrieve their reports (giving them a grace period before the account becomes inactive). What is even worse is that I cannot “upgrade my account”, so how exactly do Pingdom expect me to pay them money for their service? Do I have to sign-up again? Do I have to crawl on my knees to Pingdom and beg them to let me back in?
So here is a tip; use every e-mail you send to the customer to enhance your relationship and provide them opportunities to engage with you. At the least, make them feel good. For God’s sake, do not terminate them!
I object to naming a department “human resources”; there is nothing human about them. Maybe “rules, policies and procedures department” is an apt name for the roles and responsibility of those that claim to be in HR. More often than not, HR exists in organisations to write policies that make no sense and stifle the right of employees to enjoy their job (I am sorry; any good deeds that you can provide as examples are purely accidental and down to good management than HR).
This is especially the case when it comes to a software/technology company. But the problem here is not just HR but management in general. Why is it that people who run technology companies are the least qualified to do so? For every good example of a CEO or MD of a technology company, I can give you 10 that are bad. Where lies the problem?
In my experience, the problem lies in the all-too-obvious disconnect between leadership and workforce in the way they think, work and live. Too often, technology companies are led by charming, well-suited businessmen (read salespeople) who have no appreciation of the real concerns or mindset of the programmers they manage.
I know this well. For a few years now, I have worked in these companies; that show utter and total disregard to technologists and deal with them as necessary evil. These are the frustrations that have led me to throw down the gauntlet and challenge myself to start a company that values and respects it’s technical staff. hedgehog lab is a company for geeks, by geeks. All our directors are keen technologists and self-confessed geeks. Many will say that idealism is all good and fine but the realities of running a company are hard. Well, we shall see! You can always turn a skilled geek into a good businessman but I have yet to see a good businessman turned into a skilled geek.
To make hedgehog lab a developer-friendly company, we have started to think about everything from our appraisal process to work hours and working days.
How many technology companies do you know of in the UK that work a four day week (oh yes! we will still be sustainable; in your face overtime!)? Gone are the days when productivity was measured by when you clock-in and when you clock-out! Developer productivity is not measured in minutes, hours or days anymore.
You don’t need to innovate to build a developer-friendly company; just stick to the basics and listen to your developers when they speak. That can’t be hard can it?
We have been recently working on a top-secret Rails app and performance has been a primary consideration. Although I agree that “scaling is a nice problem to have sometime in the future“, it does not mean we throw good software design out of the window. It causes a lot less pain and effort designing something better from the ground-up than re-factoring an entire code-base at a later point.
With this in view, we set about investigating a few pointers to improving Rails performance. A note that all of these are links that have been collected from our days learning Rails from various sources on the web. I just could not let these languish in our internal wiki!
If you are one of those n00bs that are looking to learn Ruby on Rails on a Mac OS X and happen to use the unfortunate combination of Locomotive and a XAMPP-based MySQL server, you will probably be frustrated with the following error,
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
The secret sauce to solve this problem is to connect to your MySQL using an IP address (to force TCP/IP) rather than the default socket-based connection initiated by using localhost.
Simply change the following line in your Rails config/database.yml from,
Firstly, apologies if you have arrived here through your feed reader which has suddenly been flooded with every blog post made by hedgehog lab. We just deployed a massive re-design and re-code of our main website, which meant that a few things were bound to go awry. This should be fixed now, so please feel free to "Mark all as read" and move on.
Moving onto the good news, as you can see, we have taken on-board nearly a year's worth of feedback all our loyal customers have provided and spent some long sleepless nights to build and deploy our brand spanking new website. It's also a great opportunity for me to provide an update on our products and summarise our new website.
Website re-design and re-write
Most software companies are guilty of spending far too much time re-designing (lesser crime) and re-writing (greater crime) their website and internal tools every so often instead of focusing on, err, writing software for customers.
Lest you think we fell into this trap, our site re-design and re-write is actually in response to overwhelming customer feedback. Our previous site had a good enough design and a basic set of tools but there were constant complaints about both small details like font size, and big important details like issues with license generation and account management tools. We listened patiently for over a year and decided now was the right time to introduce an update. Here are some key points about this update,
One of the biggest overhaul has been in the visual/brand side of things. We have ditched our "far-too-corporate" look and adopted a visual style that we feel reflects our personality and ethics.
The product pages and content have been completely overhauled, giving a better experience when looking for information and making it easier to evaluate your options.
There is more information about hedgehog lab now, and more importantly, the much requested Team page and team information.
The license and account management section has been completely re-designed and re-written. It is now even quicker to buy and manage your product licenses from hedgehog lab.
We have a lot more exciting support-related changes and more content coming in the next few months, so make sure you keep an eye on the website.
fixx
This has been months in the making but fixx 1.9 is finally here and it brings with it a wealth of new features and updates which have been requested for a long while. Check out the Release Notes for more info and grab your copy. Here are a few big highlights from 1.9,
You can now delete projects you don't need completely from fixx.
The free user limit has been increased to 3 from 1. You can now have 3 valid users in the system without paying a penny!
fixx can now speak Spanish & German.
You can perform a 1-click migration from Unfuddle.
solomon
The past 2 months have been full steam ahead with solomon development. We have made massive progress with functionality (which included 2 re-writes of the contacts screen) but we are finally happy with the experience and UI. The beta is very close and although I don't want to give away a lot, expect a blog post and a sneak peek into both the solomon web and iPhone app soon.
One of our original aims of opening up a RESTful API for our bug tracking product fixx, was to encourage a healthy eco-system of third-party developers who can enhance and add to the functionality fixx brings and provide open integration points to third-party apps.
It has been great to see the overwhelming response from third-party developers who have spent their time and effort to enhance the fixx eco-system and we thought it would be the perfect time to thank everyone who has been working with the fixx API, providing feedback/criticism (which we always listen to and take on board), and generally writing some awesome add-ons. The following are just a few of them that we hope will be useful for those currently using fixx or considering using fixx in the future.
IDE Integration for Visual Studio and Eclipse
One of our customers, Martijn Laarman, has done a stellar job delivering a first version of Visual Studio Add-On for fixx. The project is pre-beta and is looking for people to try out the system and help him iron out bugs. There is also a project underway to bring IDE goodness to fixx in Eclipse.
Instant screenshots with Freshlog
Freshlog is a pretty nifty screen capture tool for the Mac that I personally use. It integrates with fixx and many other bug tracking tools, allowing you to capture and submit screenshots as new issues or comments to existing issues. It comes at an affordable price of $14.95 which is a bargain considering the plethora of tools and speed of updates it provides.
Source Control and more with XP-Dev.com
XP-Dev.com offers Enterprise Subversion hosting and has leveraged Subversion post-commit hooks to update fixx issues with commit messages. Even if you host your own Subversion repo, you can use a Ruby post-commit hook that allows you to do the same. Mercurial and Git hooks are also available.
These are just a few of the Add-Ons and integrations that third party developers and some of our customers have been working on. You can always find a more comprehensive list on our Add-Ons for fixx page and we would love to hear from you if you have been working on an add-on and would like it to be featured.
Since the iPad was announced to much fanfare last month, the Internet is abuzz with some people decrying it as a "larger iPhone" (what's wrong with that?) and others announcing it as the next shift in computing.
Personally, I stand between both viewpoints. I agree that it is indeed a larger iPhone, but I also see the potential a large touch-screen device provides. A majority of the current discussion around the pros of the iPad are based around how this is a consumer computing device for "your mum and your grandparents" but fails to see the larger picture around what this might mean for business and work in general.
There has been very little debate surrounding the potential of the iPad as a business device. I admit it might not work in an organisation like ours (although we still have ideas that would work perfectly on an iPad) but there are many organisations where geeks, technology, and code are a means to an end and just support tools for the core business.
The problem with imagining the iPad as a business computer arises from the instant reaction most people will have. The inevitable, "it's not a real computer" argument will be thrown about. "It can't multi-task!" "It doesn't have a real keyboard." Yet, there are so many real-world scenarios I face in daily life where an iPad would have greatly diminished the pain and improved the job a person does.
Mobile Workers
We recently had a Central Heating Sales engineer come out to give us a quote to install new boiler. I felt fairly sorry for him due to the amount of baggage he had to move around with him to do a fairly simple task of filling in a few forms (in response to a set of questions) and generate a quote document.
The process involved what must be the heaviest laptop, and stone-age wireless connectivity that took a set of rituals and prayers to set-up. He had to spend a major part of the call joking about "IT" and apologising profusely for "problems with the Internet."
I could not help wondering how the iPad could have made this entire process (which he probably repeats many times a day) much easier and more interactive for the customer and the sales person. You could get rid of all the brochures in the briefcase and convert these into electronic brochures for display on an iPad. Typing would not be much of an issue as most of the form fields were designed to be choices and number entry. Even if data entry involved a fair amount of textual data, an external keyboard would have instantly solved this problem.
The only flaw in the process as far as the iPad goes, was the ability of the existing laptop to connect to a small printer via USB to print a quote. This could be a stumbling block unless Apple allows easy Bluetooth printing or someone comes up with a printer interface to the iPad.
Data Entry in the field
A while ago, I worked on an R & D product prototype for a FTSE client in the property business, who was looking to cut their costs in relation to the time-consuming process of data-entry by skilled staff. They had highly-paid property managers who would go out to inspect properties in their portfolio, whose job it was to ensure the properties were maintained and managed to standards. However, it was clear that it was very inefficient for these property managers to go out with paper forms, fill them out in the field, and return to their desks only to type out these forms into a computer.
The solution (at the time) was to use existing smartphone technology to build mobile apps that would facilitate data entry in the field. This would allow a "single" point of data entry and cut the time spent duplicating this information on paper and on the computer.
The only real problem was that mobile phones (the iPhone specifically) were too small to really enable the interactions that we had in mind for really quick data-entry. Although the iPhone was leagues ahead of other mobile technologies, it just didn't allows us screen real-estate to build the kind of user experience we wanted. I remember thinking "I wish Apple made a bigger iPhone!" Yet, ironically, it seems like this is what makes the iPad underwhelming.
The Sky's the Limit
The interesting thing about what iPad means for computing in general and for business in specific has very little to do with the hardware and all to do with the potential of software that could be built to allow multi-touch interactions on a well developed platform like the iPhone OS. In this sense, the hardware is not really important at all. Lack of USB, camera, screen size etc. are all trivial points that might or might not have implications in very specific circumstances.
The real question to be asked is, "What kind of software is going to be built for this thing?" Then, you can start seeing the potential an iPad brings for not just e-mail and the web for mum, but how it could greatly simplify the lives of people who are forced to use computers for their daily job but don't enjoy it at all. I believe the iPad has immense potential in areas like business intelligence, publishing, medicine, education, retail, and other sectors I can't even begin to imagine. I don't know about you, but that's pretty exciting!
We've been working hard at the lab on this for the past four months, so I'm extremely proud and excited to announce the launch of our latest product, solomon. solomon is a Small Business CRM and web-based contact management app designed with small businesses and freelancers in mind.
We were hoping to launch solomon in late 2009 and I know a lot of people have been waiting impatiently. We had to hold its release back for a few months to ensure the user experience was just right.
So what's in this version of solomon?
We've really focused our efforts on making solomon ultra-fast and productive. By taking full advantage of today's browser technologies, we've made sure that solomon keeps you productive by focusing on performance, ease of use and collaboration.
Our focus in version 1.0 was productivity and response time in these four main areas:
Search
We've made search super fast, so you can find your contacts quickly and effortlessly. As well as allowing you to search for your contacts by name, solomon will also allow you to search with more complex search patterns much like a lot of today's web based search engines.
Contact Management
Our main focus in this initial release has been about allowing you to manage your contacts in solomon with as little effort as possible. solomon allows you to import your contacts from industry standard Outlook CSV files and exports to both vCard and Outlook CSV. The goal here was to provide a unified address book that you can use from anywhere.
Tasks and Notes
When working with a contact in solomon, you can immediately get an overview of all of the information for that contact as well as the tasks and notes associated with them. Adding notes and tasks is a snap using a single screen interface that behaves more like a desktop application than a web app.
Mobility
We love our smart phones, and one of our goals from the outset was to make solomon truly mobile. Building on top of the solomon API, we've built an iPhone application which will allow you to take your contacts with you anywhere. The iPhone app is currently in review by Apple and should be on the App Store within days. Our native iPhone application allows you to take advantage of many of the features of the phone like calling your contact directly, sending them an email or finding their location on Google Maps. With the iPhone app, you can also keep track of the tasks you have and add notes while your'e on the move.
Where is solomon going?
We've been using solomon internally for about 2 months now and we are really happy with the experience but thats not to say we haven't got bigger plans. Far from it! Our roadmap is bursting at the seams with features we think are really going to improve solomon and we really think your'e going to like them too.
We aren't going to commit to any one feature or specific milestones at the moment until we've given our customers a chance to have their say about what they would like to see in the next version of solomon but to give you a taste of what's to come, here's a few of the features we're really excited about getting out in a coming iterations of solomon:
Track Cases, Leads and Deals We will be introducing more Sales Force Automation (SFA) functionality in 1.1 and 1.2, which will enable you to track leads and deals you make, keep on top of relationships using cases, and track new business.
Mobile apps We are working on concepts for native apps for BlackBerry and Android versions of our mobile app. We are absolutely committed to supporting multiple mobile platforms and these apps are high on our list.
Outlook Plug-in We know that a vast majority of small businesses use Outlook as their preferred e-mail client and we have a very exciting Outlook plug-in planned that will allow you to tie your e-mail and solomon data together.
E-mail Integration We will be working on advanced e-mail integration, allowing you to write and forward e-mails directly into solomon.
3rd Party Integration A wider integration of your contact data with other web and desktop applications like Google Contacts and real time 2-way sync capabilities. Whether you want to view contact information in Gmail or access your tasks in Google Calendar, our planned OpenSocial integration will support this. We will also be supporting import and export from 3rd party systems and popular file formats.
We're excited to announce public availability of the Hosted version of our bug tracking product, fixx. This has been the single biggest request we have consistently received over the past year, so we have heard you and acted on it!
Hosted fixx is a great and flexible way to get started with your own instance of fixx without having to set-up your own server and configure it. Despite how painless and easy it is to run your own instance of fixx, we know that many organisations love the ease of having someone else manage their software using a software as a service (SaaS) model. It is also a great way for organisations without IT staff to get started with fixx.
Unlike traditional on-demand/SaaS models, we have gone all out to give you the power of having your own dedicated hosted version of fixx that you have absolute control over. This means, you control when your software is upgraded and which features you want to turn on. We handle all the boring work like configuration, back-ups and upgrades.
fixx Hosted comes with absolutely no restrictions on functionality. You get every feature of the installable version, including unlimited users, projects and issues. Which other hosted bug tracker or project management tool offers that? The only thing that is limited is disk size for attachments but even that is generous with 20GB+ space, which is limitless for most common usage.
This is only the beginning for Hosted services from hedgehog lab. We hear you loud and clear on a hosted solomon and we are working hard on it. For now, we want to start slow and get feedback from our community on how we can improve our hosted offerings. Keep an eye out on our blog as we make constant improvements while delivering advanced functionality in our product roadmap.
I have always wanted to publish a blog entry on our experience developing a game for the iPhone earlier on in the year but never got around to it due to things getting extremely busy at the lab (as you can see from the distinct lack of rants from me).
However, Derek Yu has beat me to it by publishing a most excellent article on Finishing a game. Must read for anyone interested in indie game production/development or any budding game developers.
We are pretty excited about this so I cannot wait any longer to announce that after a lot of whiteboard work, arguments and development, solomon 1.1 is finally here.
What's notable in this version of solomon?
Deals and Sales Management
solomon 1.1 introduces one of our most requested features and something we had in planning for a long time, Deals. Deals allows you to manage your your sales process and opportunities by tracking the progress of all your leads. They give you clear visibility into your sales pipeline and are a great way to organise your sales effort centered around a "project" approach.
Have a look at our earlier earlier sneak peek for more details on interesting features in 1.1.
Other than this major feature, 1.1 includes 84 other bug fixes, improvements and features that were requested by our customers.
Last month, BlackBerry announced the PlayBook to much fanfare and press coverage. I managed to catch the live announcement and demo from the Developer Conference, and I must say it was a pretty interesting demo. Of all the tablets announced (iPad included), the PlayBook is probably the most exciting for us as far as our work with Enterprise software is concerned.
It's not Android/Chrome OS
In a world where everything that is not an iOS tablet is an Android/Chrome OS tablet, the BlackBerry OS introduces a refreshing and all-important third alternative. Yes, it is very similar to iOS (the Mail app on the PlayBook is a striking resemblance of Mail on the iPad) but a first look at the demo reminded me more of WebOS than anything else.
QNX seems to have been a very capable company and it appears that not only does the BlackBerry Tablet OS look great, it has a solid mobile platform underpinning it.
Size
Steve Jobs beat me to it but I think a 7-inch tablet just doesn't seem like a great fit for a tablet. Having owned an iPad for a while, I think that a 10-inch screen offers the optimum tablet experience for me. If I need anything smaller, then I would rather drop down to a smartphone screen size rather than anything intermediate.
However, I have not yet held an actual 7-inch tablet in my hands, so I will reserve judgement until I use one.
Who is this aimed at?
I guess that is more of a rhetorical question, as the answer is clearly (from PlayBook's micro-site and spiel) the Enterprise. Therefore, I find it curious that they chose a name like PlayBook for their flagship product in the Enterprise Tablet market.
I will go out on a limb and say that the PlayBook will be an easy sell to Enterprises who have invested hugely in BlackBerry infrastructure with it's immediate integration with BlackBerry servers. I see this spreading quickly in the Enterprise.
It is clear from the demo that BlackBerry wants to pitch this as both a great Enterprise tablet and a cool consumer tablet. A lot of the demo focuses on how "cool" the media capabilities are and a lot of the benefits are squarely aimed at the "iPad crowd". Flash, for example.
I could not help laughing when one of the much-taunted features at the live announcement was "full POSIX support". I know the conference was aimed at developers but clearly BlackBerry is in 2 minds here about it's target market.
The iPad Killer
Like it or not, the inevitable comparisons with the iPad have already started doing the rounds. I personally will not be swapping my iPad for a PlayBook anytime soon but I did notice that with the device not coming out until early to late 2011, it will effectively be competing with a 2nd Generation iPad that could address most of the current differences.
To me, the PlayBook is a credible alternative to the iPad and it's great to see competition heating up in this space with the Samsung Galaxy Tab adding an Android alternative to the mix.
I am more excited about the PlayBook (for selfish reasons) due to the penetration potential it has in the Enterprise and the business opportunities it presents. However, what is more exciting, is that tablets are here to stay and ready to change the mobile computing landscape.
We launched our hosted bug tracking service 5 months ago hoping to give customers an on-demand choice for our most popular product. We did not anticipate the great positive response to this from Enterprise customers and 5 months later, we will be counting multi-national organisations like AXA and Starbucks within our customers.
Since then, we have successfully launched solomon, our web-based CRM tool to generally positive reception, and we are working hard to implement features our community has requested. However, as with fixx, the single most requested feature is to have a hosted, on-demand version of solomon.
With this in view, we are excited to announce hosted plans for solomon.
Hosted solomon is a great and flexible way to get started with your own web-based CRM without having to set-up your own server and configure it. Despite how painless and easy it is to run your own instance of solomon, we know that many organisations love the ease of having someone else manage their software using a software as a service (SaaS) model. It is also a great way for organisations without IT staff to get started with solomon.
Unlike traditional on-demand/SaaS models, we have gone all out to give you the power of having your own dedicated hosted version of solomon that you have absolute control over. This means, you control when your software is upgraded and which features you want to turn on. We handle all the boring work like configuration, back-ups and upgrades.
solomon Hosted comes with absolutely no restrictions on functionality. You get every feature of the installable version, including unlimited contacts and deals. Which other hosted CRM tool offers that?
Starter plans
Although fixx has seen great adoption in the Enterprise, we heard feedback from a lot of our smaller customers stating the existing plans we offered were geared towards larger businesses and there was little choice for small businesses/start-ups.
We are changing that from today by announcing Starter plans for both fixx and solomon, which means you can get all the on-demand goodness and benefits for the a low starting price of $49 per month.
We have more exciting roadmap features and plans to announce in the coming few weeks but we once again welcome feedback from our passionate community of users.
With the exponential growth of smartphone sales pioneered by Apple's iOS platform and Google's Android platform, a lot of brands and businesses are starting to factor mobile apps and a mobile strategy into their marketing and operational activities.
In this mobile app gold rush, there is a general (and false) perception that the best way to reach the largest number of customers is to target every major mobile platform out there. On the surface, it seems like a good strategy to ensure your app is available to a wide array of users but fails to take into account the Pareto Principle (or the 80-20 rule). Applied to mobile apps, the Pareto principle would translate into "80% of your customers/engagement comes from 20% of the market". In this case, the 20% being Apple's iOS platform.
Finally, an often overlooked fact remains that Apple's iOS environment is a great test-bed for any innovative app concept you have. If your app is a success on Apple's platform, then it is very likely it is a good candidate to be ported to other platforms (as is the case with hugely successful games like Angry Birds).
With development budgets heavily restricted and the nascent stage of the mobile apps market, my advice to our customers is always to start where you will see the most ROI than invest large sums of money on a multi-platform strategy and realise that 80% of your efforts (i.e. developing for platforms other than Apple's) only return 20% benefits. Thankfully for us, it's a strategy that seems to be working.
Nokia has had a pretty bad decade at the start of this millennium. Declining smartphone sales, abysmal reviews for their latest phones and general apathy from the developer community have reduced Nokia to nearly irrelevant in the smartphone community. Although Nokia is still a dominant force in the mobile market in general, very few people are excited at anything the company has to say.
Given this climate, I am not surprised that Nokia CEO Stephen Elop has published the now famous "burning platform" memo that is doing the rounds in the press this morning. I doubt anyone who follows the mobile market would be surprised at the observations that Elop makes in his memo but it is fascinating watching how honest he is about Nokia's shortcomings.
The most interesting bit to come out of this memo is Elop's hint at an upcoming announcement this Friday that promises to reveal the way forward for Nokia at the company's Capital Markets Day event. What is interesting and worth watching about this event is the wild speculation that Nokia might announce that they are going to adopt Windows Phone 7.
I know the mobile pundits will laugh at how futile and ridiculous this move would be. On the face of it, it seems like Nokia is giving up even without trying. Vic Gundotra, VP of Engineering for Google, tweeted "#feb11 "Two turkeys do not make an Eagle", alluding to the fact that a Nokia and Windows Phone 7 is both possible and doomed to failure.
However, I strongly believe that abandoning their "burning" platforms like Symbian and adopting Windows Phone 7 could be the smart move Nokia makes this decade.
Nokia has always been great at making good hardware. The Nokia 6310i is still the best business phone I have ever used and that is saying something considering I am a staunch iPhone user and Apple fanboy. Where Nokia has failed is in putting together a great software platform and integrating it into an ecosystem that worked seamlessly with the hardware for customers and developers alike.
Developing software for Nokia phones has always been a difficult path for developers that many took while Nokia held market dominance. However, Apple and Google have shown that there is a better way when it comes to smart phones. It would take a monumental effort on Nokia's part to make Symbian and/or MeeGo into real competitors to iOS and Android.
Why not just adopt Android then? Isn't it open, innovative and market leading? This would seem to be a safe choice given the liberal Android terms but the risks Nokia runs is that it will have no advantages against the hundred other manufacturers developing Android phones. Android just won't give Nokia the competitive difference in the market and I doubt Nokia wants to become "just another Android manufacturer".
Windows Phone 7, although very late to the market, is generally accepted as a great technical platforms. By not copying iOS and Android, Windows Phone 7 has provided a credible user experience alternative to people who want to use smart phones. It has even been pitched as the platform "for normal people who aren't addicted to their phones". Reviews across the board agree that the platform is sound and has lots of positives.
What Windows Phone 7 is lacking is a credible manufacturer who can put their efforts behind producing excellent hardware that complements the platform while pushing the devices as flagship products. If Microsoft can accommodate Nokia by relaxing it's licensing terms and strike an agreement, I think we can look forward to seeing a third credible alternative to the iPhone and Android-based devices. Nokia and Microsoft could well be onto something great here.
Can someone just tell that to Steve Ballmer and Stephen Elop?
We know that not everyone loves going through a lot of text or pages of information to find out more details about a company. To help solve this, we have been working hard on trying to introduce short, snappy videos to our site to give people a concise and more "interactive" glimpse into what we are about.
We are really happy with the first version of the video and I wanted to share this with the world. We would love hear your criticisms, feedback, suggestions or praise. The video was produced by the excellent folk at YourFilm and I would definitely recommend them if you were looking for someone to produce any interactive or corporate videos.
