Category Archives: Blog

Quick, good or cheap – choose two

I often go to start-up events and I am still suprised how few people even bother to do even basic sanity checking about their business idea.

Either something like:

“I want to build the next Facebook”
“How much budget do you have?”
“About £500 and that includes marketing”

Where they have no idea about manpower or infrastructure costs, how they will monetise it or anything else…

“I want to build a site where people can get little fixed-price jobs done”
“You mean like”
“You mean there is already a site like that?”

Never even bothering to do basic research…

“I want to build a site where people can buy our [dog] products, but I need it completely writing from scratch”
“Our software should be what makes us unique!”
“So you want to sell this e-commerce platform to other people?”
“Nope, it will be ours and ours alone”
“Why don’t you customise an open-source platform?”
“Because other people can copy us easier”

Where they just don’t understand why they are asking for what they are asking for.

The main thing most of these people have in common is that they are not playing to their strengths. Their strength is certainly not software development or website design but they think they know enough to manage a project in these fields. Unfortunately, most of these people end up with developers that know little more than they do and a project doomed to fail.

They have failed to even do the basics of validating that the market exists and who the existing players are, what problem they are trying to solve and if they have defined requirements (like writing your code from scratch) why this requirement even exists.

For me the thing that saddens me the most is that many of these people have sunk weeks and weeks of evenings and weekends, planning what they want the site to look like without even bothering to lay the groundwork; frequently not understanding that most of what they have designed is just composed of basic design patterns.

Spending an hour with an expert (me or anyone else) could have saved them a lot of wasted time and in some cases money.

If you do feel that an hour or paid time with myself would help you get your ideas straight, then you can contact me on mike-at-technomonk-dot-com (replacing the necessary parts) or +44(0)7950892038 / skype:darkflib


The phrase in the title comes from an old idea in that you can only have 2 of the 3:

  • A good and cheap implementation wont be quick.
  • A cheap and quick implementation wont be good.
  • A good and quick implementation wont be cheap.

There is some truth in it, but with the advent of frameworks and open source platforms like WordPress and Drupal, it becomes less so.

Instant Messaging

I was asked after my last post what I used for instant messaging. The answer is kinda interesting in my opinion.

As some of you know I am a privacy advocate, but try to also balance that with ease of use and ease of integrating with other people.

I run my own XMPP server which I share with a number of collegues. This is running of Prosody an open source XMPP server. We use the MUC module to host a number of conference rooms where our bots and other notifications are sent.

In addition to this I also use Skype, not because I trust Microsoft to not sell my contact info out to the NSA, but because it reduces the friction of contacting me for a number of people. Forcing them to use my private XMPP server (even through federation) is too big a hurdle for them to jump.

Life-p (My move to Synety and coming blog posts)

For those that are in contact with me regularly, you will be aware that about 2 months back I took a position with an established startup called Synety.

I needed more stability in my life and while I dislike working in a corporate hierarchy with all the politics that go with it, I felt that Synety and its small size was a good fit for my move back into the that world.

I am pleased to say that 2 months in and I am enjoying the role. I am being challenged on a daily basis, but  I also have the support of a great team who make these challenges manageable and the support of a great management team who are willing to allocate resources to do things right, rather than having to cobble something together using whatever odds and sods are lying around at the time. It is a refreshing change from some of my previous roles which were beset by political huddles at every turn and budgets that were inflexible.

I hope to share some of the knowledge I am gaining (nothing proprietary obviously) in the coming months in a series of posts that help explain some of the technologies behind some of the changes that I am making within Synety by applying the same techniques and technologies to my own projects.

This will probably include some details of the use of Jenkins, FPM, RabbitMQ and other technologies and how they can be used effectively to build more efficient workflows, application architectures and to reduce technical debt through automated code checks.

If there is anything in particular that you would like me to cover, then please drop me a line at mike at technomonk dot com

A look at the new rackspace cloud

I have been very lucky to be included in the first rollout of the new rackspace cloud and while it has been live (to me) for a few days, I have only just had a few minutes to have a play with it. Continue reading

Lessons I learned from building startups

Sysdom isn’t my first startup, it isn’t even my second, but comes some way down the list at 3 or 4 (or 8 or 9 depending on whether you want to count startups that I didn’t have equity in). In that time I have made mistakes (oh so many mistakes), but I have learned from them and tend to make completely new mistakes the next time around. 😉

I will try to distil some of that hard learned knowledge into a something that others can learn from so they don’t have to make the same mistakes I have.

Happiness is everything

If you aren’t happy going to work then you really shouldn’t be doing this. You will work harder for something you enjoy and unhappiness will spread to colleagues and customers. In the end it will make or break the business.

Everything has a cost

While you might not value your time during the initial stages of building your new enterprise, your time does have a cost. Any time that you spend reinventing the wheel or building solutions to a problem that can be solved cheaply by using an outside service or product is time that you are not concentrating on your core product.

Everything has a value

Any time you are building solutions to problems you are creating value. While it might be difficult to turn this value into money (ie. by productising it) it quite often can be used to build reputation or build attention for you and your business.


If you don’t have a vision or aim, then you are essentially just randomly hitting keys and hoping to come up with the complete works of Shakespeare – it is unlikely to happen. Start with a problem that vexes you regularly then solve that problem. It is quite probable that other people face the same problem regularly too.

Never take outside money

Taking other peoples money is never a good idea for a small startup. It gives them a massive lever in the direction of the business and often results in the business going in a way that you dislike. Result? You end up getting dissatisfied with the business and work suffers.

Don’t give away equity

Giving away shares in your business should be one of the last resorts. It can mean that employees will work harder, that investors may bring in expertise to assist in the growth of the business, but unless done right it will mean huge risk and little benefit.


If you aren’t breaking new ground then you are really just building a ‘me too’ product. This isn’t always a problem, but makes it hard to differentiate yourself in a market filled with clone products. Innovation is key: make it simpler, faster or do something no other product does.

Pivot and think laterally

Inside almost any solution is the key to solving an even bigger problem. Build a good solution and you often have other products that can be brought to market with minimal effort.

Be Lean

Even if you do have cash available, you don’t have to spend it. Do you really need that flashy usb coffee cup warmer? That £800 office chair when a £100 will do? The same goes for infrastructure. Why buy a £5k server when you can build using cloud servers (Rackspace Cloud and Amazon Web Services for example) at a fraction of the price and gain redundancy to boot. Yes, it will be hard, but these challenges will make you face up to the real problem – that of bringing in customers and cashflow.

Fail fast

If the problem isn’t really a problem or your solution doesn’t adequately solve it then don’t be afraid of quitting before you sink too many resources into it and move onto the next problem.

Don’t quit at the first hurdle

If you find a problem that you can’t solve initially, don’t quit. Other people will be facing the same issue and a solution will mean you have an advantage over them. This doesn’t mean you should sink resources into something that is unlikely to be able to recoup them – fail fast in this case.


You are unlikely to get it right first time. Build a product then improve it one problem at a time. Sometimes it will look nothing like how the original concept was envisioned – this is fine and normal.


Metrics and logs should be an integral part of everything you build. If you can’t measure it you can’t improve it. Web logs are a good start, but alone don’t tell you much besides who is visiting and how many times they have visited. You also need to know how many resources you are spending on servicing each visitor.

Low barrier to entry will mean many competitors

If the solution is easy, then many people will build one and compete with you. For example, there are many projects cloning 37signal’s Basecamp product or bringing basic telephony services to market based on the open source asterisk project. If the problem is harder, then you will have less competitors and will be be able to price your product higher.

Find your niche

Your niche should be somewhere where you can dominate, where few competitors exist and you can grow unhindered. For example, applications for pig farmers – there are a lot of them around the world…

Some competitors will always race you to the bottom

Racing your competitors to the bottom is generally a losing race for everyone involved. Without the cashflow to innovate and support your product, your service will suffer and your product will likely stagnate. Charge a fair price, explain what your customers are paying for and point out why a lower cost solution isn’t suitable. 37Signals have been releasing uptime and customer happiness metrics for just this reason.

Stop doing things that don’t get you towards your goals

If it doesn’t get you closer to your goals then it isn’t worth spending your time on. Stop doing it, or at the very least outsource it.

You aren’t perfect

It is unlikely you will have all the skills required on your own. Don’t be afraid of buying in talent to bolster your skill-set.

I hope that this has been interesting and please do leave any additional lessons in the comments below.

MongoDB Journalling

A quick one if you are wondering about MongoDB and Journalling (especially on Debian/Ubuntu from the MongoDB repo) .

By default mongodb will generate 3gig of journal files in /var/lib/mongodb/journal this is far from ideal if you are running on a Rackspace CloudServer or smaller VPS.

There are two easy solutions:

  • If you are running as part of a ReplicaSet then you can choose to go without journalling altogether with the

    option in mongodb.conf.

  • Alternatively you can request that MongoDB uses smaller preallocated files for journalling use the

    option in mongodb.conf.

To also reduce some usage in your datafiles there is the also the

noprealloc = true

option, however I don’t see this as particularly useful considering the preallocation starts pretty small and only grows as your data does.

Bash Tip #1

Often when operating on the commandline you may want to re-execute something with elevated privileges. There is a shorthand way to do this rather than either cutting and pasting or retyping the line.

mike@mike-P35C-DX3R:~$ updatedb
updatedb: can not open a temporary file for `/var/lib/mlocate/mlocate.db'
mike@mike-P35C-DX3R:~$ sudo !!
sudo updatedb

The first updatedb command needs to be ran as root, initially I forgot the sudo so it couldn’t update the database. Running it again with !! meant that I didn’t have to retype the whole command… Obviously this is more impressive with longer lines…

Why a sysadmin?

I never intended to become a system administrator out of choice, it just kinda happened. What follows is a rough account of my history of computers since around 1995. I omit mentions of specific companies I worked for and with and any systems I owned prior to 1995 (of which there were many, but no PC compatibles). This isn’t a perfect recount, some details are lost in the mists of time, but I hope it gives you the gist of it all. Continue reading

Ubuntu 11.04

I upgraded from Ubuntu 10.10 to 11.04 and so far I’m impressed.

Besides a couple of Firefox plugins that aren’t available on Firefox 4, everything seems great. Although I immediately disabled unity and went back to the classic desktop as I just don’t like it.

Firefox is blazingly fast compared to 3.6 and just seems far more polished.

No apparent changes in Thunderbird or Pidgin so far, but then again I wasn’t expecting any.

Hopefully I wont notice anything broken over the next few days as I use some of my other tools and apps.

Managing Developers – a top 10 list of why you don’t get on well with your developer

Managing geeks is hard, not because there is anything fundementally difficult about it but because managers just don’t understand them. A few people have written at length about this online including some fairly well known blogs and many books.

Developers are subset of geeks that while similar do have some subtle differences over the average geek. The main points are as follows.

1. Not paying your developer what they’re worth to you.

If you’ve got a great idea that wil produce a great amount of money, don’t expect your developer to work on the project for a low amount of money, especially if they’re aware of what their programming will produce for you. Geeks value fairness and asking them to create something that someone else will reap all the reward for just doesn’t strike most as fair.

2. Not meeting your developers basic needs.

It’s not just about the money. It’s about having something to eat or drink when your developer would like to or being able to clear their headspace when they need to. Find out what your developer needs and likes, and make sure they have some. You don’t have to go as far as google in trying to give them everything that they could desire though.

3. Not making sure your developer has all the tools they need.

If your developer is working on outdated equipment with outdated software, you can expect outdated results. You would be surprised how inexpensive new laptops are, and how much faster the project can be completed with newer equipment.

4. Not ensuring your developer has limited interruptions and distractions.

Newsflash: Developers hate unproductive meetings. They don’t need to know what your latest and greatest idea is unless it is directly related to the project they’re working on. They also don’t like phone calls from end users being transferred to them to deal with. They’re not a help desk. Likewise, asking them “how’s it going?” six times a day does not speed things up. In the same sense, do make sure they’re not being distracted by bright lights or shiny things.

5. Not forcing your developer to do something different.

Developers, just like anyone else, get into ruts. It’s important for you as an Employer to make sure your Developer does see the light of day now and then, no matter how much they complain. A change of pace is always a good thing.

6. Not bragging enough about your developer.

Again, it’s not just about the pay cheque. When you brag to other people about your Developer, and it gets back to them, it gives them an instant self esteem boost, which will translate into more productivity.

7. Not describing end-goals in detail to your developer.

Developers do what they do because they possess a unique skillset. A basic of that skill set is being able to reverse engineer things – even an idea. More often than not, when a developer knows the end goal, they can usually cut the production time by a substantial amount. They can also make you aware of pitfalls in your overall idea.

8. Not understanding the schedule your developer keeps.

Some developers are known as “farmers“. Those are the ones that work when the sun is up, and sleep at night. Others work best during the night (because of all the interruptions they get during the day). Still others work what amounts to swing-shift hours. It’s up to you as a Manager and Employer to find out what works best for your developer, and (provided you can live with those hours), make sure your developer is allowed to work them.

9. Not taking the advice of your developer.

The quickest way to kill a relationship with your developer is to ask them a question, listen to their answer, then not take their advice. If a developer gives you an answer, it’s because they know the answer – that’s how developers’ brains work. If you then do not accept the answer, you’re basically calling the logic and intellect of your developer into question. They will reciprocate. (As a extension of this, don’t simplify a conditional yes into a solid yes, the developer gave the conditions for a good reason and discounting those reasons often causes issues at a later date.)

10. Not giving your developer the freedom they need to develop.

Yes, your project is incredibly important. Yes, it’s going to put the bread on the table. However, consider what would happen if you told your developer to take 20% of their paid time and work on a project that interests them. Google and many other creative development firms do this. They understand that keeping the developer’s mind engaged is a key component to the developers happiness, which is directly linked to the success of a relationship and project. Additionally, sometimes projects done in this 20%-time can be far more valuable than most people realise and while you might not understand the value your developer does, so talk to them about their projects.

Developers aren’t normal. They’re not ordinary. They’re not complicated, either. It just takes some basic understanding of their nature to ensure a positive relationship with them.

— with thanks to Andy Stetzinger