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.
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.
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 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.
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.
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!
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.
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.
Since joining The Lab, I have had the pleasure of working with Django a whole lot more. In this time, I’ve noticed a couple of tricks / niceties that make development run a lot smoother, here are a couple…
Evolution of debugging
Web development is full of little debug tricks, usually involving variations on variable inspection. Django provides lots of such useful methods, and I have found myself progressing through more powerful solutions as I discover them.
return HttpResponse({variable to inspect})
As far as I am aware, this is the most basic form of debugging. Just stick that string at the point in your view where you wish to examine the state and it will short circuit the view code with the variable result. It’s the Django equivalent of alert(). In a lot of development, this will suffice, however this is limited to the scope of view code.
print {variable to inspect}
Usable in any Django Python code running on the Django development server, lob this in and it will publish the result to the console. I usually put some \n’s around it to easier spot it amongst the response codes. For me, the limitation of only being able to use it in the dev server isn’t a big one, because that’s where I do most of my development. The only real issue is when I realise that I want a different variable, change the code and restart the server. Some debug context (solved by the next method) would be nice.
(#5677 suggests that this is bad form and could cause troubles when using over mod_python, depending on your set-up.)
raise Exception({variable to inspect})
I realised this beaut through the most excellent Django wiki. By raising the exception (with debug = True in your settings.py), you force the lovely Django debug page to display - chocked full with helpful info, tracebacks and context - along with your inspected variable at the top.
import pdb; pdb.set_trace()
This is my personal favourite. It activates the Python Debugger and allows you to step through your code and interactively check each variable.
Type “help” for a list of commands, “args” prints the arguments sent into the currently running function, “next” executes the next line, p {variable to inspect} prints a variable, pp {variable} pretty-prints a variable and continue tells pdb to run the rest of your code (unless we hit another breakpoint).
My google-fu has recently revealed django-logging, a Django middleware component which provides the ability to spit out variables in your view and based upon the Python Logging module. I am yet to try this, but it looks like another ace string in your Django debugging bow.
In addition to these, there is always the incredibly helpful <% debug %> tag, to spit out your context variables while template coding.
IPython
IPython has spoiled me rotten. It is an enhanced Python REPL environment with a lot of extra bells and whistles. First off, the code completion is fab. django-admin.py recognises that you have IPython installed, so typing “./manage.py shell” allows you to import your models and inspect them with a quick “.<TAB>”.
IPython makes reading code / docstrings a breeze - you don’t know what django.models.cheesypuff is? type “django.models.cheesypuff?” to get information and documentation about the object / method printed to your screen. That doesn’t help? then try “django.models.cheesypuff??” to get documentation AND source code. It’s brilliant.
The best bit about IPython (apart from the above and it also having access to your system shell) is that it is scriptable (in Python, of course). So all sorts of nice little tricks can be used to make life easier, one of my favourites is this little snippet. It tells IPython to automatically import any model associated with your current Django project, I’ve edited mine slightly to print the names as they’re imported so I have a nice index of the models available to me without having to traverse lots of models.py files.
In short, IPython is a fantastic tool - any work I do on querysets or databases I interactively run through in that shell first - it makes it easier to quickly catch gaps in my logic. IPython also stores all of your history (type “%history”), so you can easily copy and paste that into your editor of choice. There’s plenty I haven’t discussed (if you paste in doctests, it strips out the >>>’s allowing you to run them with a quick ctrl+v), but I’ll leave you to have a play.
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.
At hedgehoglab we pride ourselves on the user-centered approach we use in designing our software, with our core product fixx seeing a number of iterations over the past few months, primarily in terms of UI design but more importantly in information architecture surrounding the views and the simplicity of use.
The process that we currently use consists of first deriving use cases of how the user will perform each operation in the system (in the form of user stories), then on to quick mock ups of real application screens in the form of wireframes (using a standard layout and component library) and finally short iterations of focused review by the entire team. We repeat this process until every use case of the system is addressed from a user perspective.
The problem with such agile reviews and lightning changes of the UI and wireframes is that it leaves some poor soul, namely me, to reflect these changes in the wireframes ready for another review. A time consuming job without the right tools believe me!
After hearing many good things from other Information Architects, we originally tried Visio for a while in the hope that this would allow for quicker iterations, but I found Visio lacking in visual appeal and there was always a bottle neck in duplicating effort by translating most Visio wireframes into visual designs after every iteration. In short, Visio sucked at providing quick turn around in terms of having realistic application screens designed.
The second option was opting for mockups in XHTML, thinking we’d save time further down the line when we could just tag some CSS, refine the XHTML and lo and behold, have a completed view. This, however, proved more effort than estimated with the intermediate & final CSS changes and mark-up tweaks ultimately ending in a mash-up of good and bad code, something we ended up throwing away and opting for a re-write. We also found that XHTML wireframes did not allow the flexibility or speed of change we required to make the wireframes as visually complete as possible.
So, what is it that has me ranting about wireframes and turnaround?…
Although not comparable to the likes of Photoshop and Illustrator (tools my designer chums swear by), Fireworks lends itself well to the needs of most web developers when it comes to slicing and dicing the visuals ready for a quick conversion into finished XHTML and CSS. It also allows us to create wireframes that are visually rich and are as close to the completed product as we would like. This also eliminates the step of producing plain wireframes in Visio first and then designing them out in a graphics package.
Working with Fireworks the past few days has seen about 10 iterations of the fixx UI go from a 5 hour job to no time at all. Each change was painless and immediate (and visually correct for everyone to review). Fireworks does a good job of keeping your pages and layers organised meaning exporting them into a reviewable image format was effortless and because Fireworks is out for both windows and mac (sorry Ubuntu fan boys, no Linux yet), we can all chip in when we need to and work on the UI of the system.
The end result? The fastest and most visually stunning wireframes & mock-ups I’ve produced in a long time with the advantage of ready-made visuals! All they need now are a little bit of eye candy thrown in, in the form of icons and content and we are away!
If you want to see sneak previews of the fixx UI we have put together keep an eye out for my next post where i will be discussing some of the changes we have made to the UI with plenty of screenshot goodness. Oh! And did I forget to mention that fixx will be entering internal beta soon at the lab?
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!”
“SIMON! Introduce yourself!”
No way!
“Introduce yourself…”
Ok! …I’m Si! …the new guy! …be nice to me cos I’m shy!
Erm, yeah..anyway. “People” have been nudging me to get on the ol’ blogaroonie to say “Hi”, but apparently, that modern masterpiece above wasn’t enough / could be considered slightly creepy.
As you may have gathered, I’m Simon… or Si… or the douchemeister general, and I too am a new hedgehog lab employee. My official title is, “Director, Research & Development”, but that’s only cos “Code Playboy” was taken. By Sarat. It essentially means that I get to dabble with different technologies and tell people about them. Just to give some context of what I mean by “different technologies”: I’m a huge fan of Python and the Django framework, I think that XMPP has a lot of potential with regards to APIs, and I believe that data portability is going to be huge.
A couple more important (and somewhat religious) tidbits: I’m a Linux guy myself (they’ve already got me setting up Ubuntu servers up here), and my editor of choice is VIM (not double jointed enough for that OTHER one).
I have joined from a larger company, where I worked as a front-end developer of sorts for about 18 months. Being at hedgehog lab is a completely different ball game: in a smaller company you contribute to pretty much every area, whether that’s saying “good idea, let’s go with it!”, suggesting an alternative, setting up a Ubuntu server, configuring software, fixing a bug, or playing with some wireframes, I have done it. All in the space of a month.
That has its good points and its bad (primarily that there’s always work to be done!), but it gives me the impression of having more input, and the lack of any major approval hierarchy (beyond, “Sarat am I ok to try this…?”) sees a very quick turnaround in getting stuff from idea stage to reality.
Needless to say, it’s great at the lab. I hope to bring you a new entry (hopefully with more substance) in the near future.
As a new member of hedgehog lab (and what is fast becoming a custom here), I would like to take this opportunity to introduce myself and my role here at the lab!
My name is Ashley Green and I started working here about 3 weeks ago. My role within the team is Developer, Technology and Products (I love my title)!
I am a recent BSc (hons) Computing Studies graduate from Northumbria University in Newcastle which I graduated from in July last year. I then went on to briefly work for a digital agency and it was after I worked there when I discovered hedgehog lab and over the past few months I have heard so many good things about the company and read some really good recommendations that I knew they were building something which I really wanted to be a part of and so far I am really enjoying working here. I am not sure how many people can actually turn around and say that they enjoy their job, but I love what I do and the atmosphere within the lab is really encouraging.
So what do I do; well, in the short amount of time which I have been here I have had plenty of training provided by my fellow team members to help me get upto speed learning cool new technologies like Struts 2, Hibernate and Spring.
I have already been given responsibility to work on an exciting new project called Solomon, which is a knowledge base for collaborative teams and customer support (hint: Solomon was a wise king). The project is currently in the inception phase and we will be bringing updates to you as soon as possible.
I will also be responsible for spearheading the social computing and networking strategy for the lab, so if you’re on Facebook, LinkedIn, twitter etc then please look us up. I am busy working on new strategies to ensure that you can always find us and engage with us no matter where you are, so I will keep you updated!
It is refreshing to use my creativity and being able to voice my idea’s and opinion’s to the team, which are always considered, regardless of how rubbish or ingenius they might be. The main thing for me is that I am valued as a team member and I have the support of my fellow team members. I get to work alongside people who know what they’re doing and are passionate about their work, which is really what any company in this industry should be about.
Well thats about it for now, this blog was really just a bit of background information about me and my role so if you want to know anything about me then please leave a comment or contact me by email and I will answer all of your questions, but don’t forget to keep checking our blogs and website.
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.)
Javascript is now part of a list of mainstream technologies on which the latest web applications and Web 2.0 is being built. Yet, it is surprising that a majority of Javascript code and developers seem to be stuck in the procedural paradigm where endless functions follow one another without any code organisation.
This is not an inherent problem in trivial systems but when we are heading towards SOFEA (Service Oriented Front End Architecture) and more applications are becoming browser-based, it can become a nightmare trying to maintain all the Javascript code. This essentially means that even where there is good use of object oriented Javascript, you could end up writing a large majority of code to just load, instantiate and configure objects.
However, while developing fixx (though we use some cool frameworks like jQuery), I noticed that we ended up writing endless amount of code to just instantiate objects and wiring up dependencies in these objects.
In a recent eureka! moment, I decided to do something about this on our last “lab day” and write an IoC container in Javascript. The result of this is Squirrel. As you guessed, it is “an IOC container in javascript”.
The current version of Squirrel is designed to ease the development of fixx client-side Javascript, allowing a greater decoupling between the complex objects that make up client-side code in fixx and resulting in code that is easier to test, maintain and extend.
A word of warning that Squirrel is currently in it infancy, but provides enough of an implementation of IOC to work with simple client-side applications.
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.
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?
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.
