Archive for the ‘Uncategorized’ Category

Business and Work 2014

Wednesday, January 7th, 2015

I went to a lecture recently and the CEO of Runtastic spoke. He said: you don’t “win or lose”, you “win or learn”. 2014 was a year of learning for me. Some of it was good, but some of it was definitely in the “you win or learn” sense of learning.

Collecting on debts

Many customers thought they would just order software from me and worry about paying it later. (The word “later” in the sense of tomorrow in “Alice in Wonderland”, i.e. not that indistinguishable from “never”.)

Here are two approaches I discovered which worked well:

  1. I developed a website for one customer, and she refused to pay, on the grounds she didn’t need the website any more. I took her to KSV (debt collection agency) and they did manage to collect the entire amount. It took 6-9 months but was pretty painless. I didn’t have a contract with her, but I had emails saying she was happy with the work, and this whole process only kicked off after 3 months of non-payment. I understand, in Austria, f you don’t dispute an invoice within one month the invoice is considered “accepted”. So because she “accepted” the invoice, she had to pay.
  2. With one other customer, who “definitely” wanted to pay according to him, but “later”, I finally stumbled upon the following approach which was successful. Building off his assertion he “definitely” wanted to pay, I asked him until when he wanted to pay. He said a year thence. I said “OK, take your entire debt, divide by 12, what you’re saying is, you’re happy to pay this on a monthly basis for the next 12 months?”. He couldn’t really say no.

Debts are going well, I hardly have any debt owed to me left. (And even if the customers were to stop repaying, at least I’ve collected a significant portion of the debt, which I wouldn’t have done had I not acted.)

Q1/Q2: Merging then un-merging (catastrophe)

I went into 2014 with two employees (MartinL, DavidZ) and not a great deal of work. And the work I did have, was for customers who were enthusiastic about the word “payment” only when combined with the word “later”.

I acquired a new customer, who were a general software development house, partly owned by their main customer, which was basically run by the same people. This main customer was developing Java Enterprise software, with a huge stack of server-VMs, Maven, ORMs, Spring, C# Windows thick-clients, Lua mobile client, and so on. Not surprisingly, despite having modest functional requirements, it (a) was large and complex software, and, as a consequence, (b) didn’t work. They needed our help. So far so good.

The software development house suggested merging their company with mine. They had 4-5 people, 2-3 customers (incl. this main customer with the Java software). I had 2 people, 3-4 customers. If we merge our resources, all customers would have access to a larger team, all employees would have access to a larger pool of customers. In principle this sounded good to me.

They insisted I become salaried at their company. The new company would continue to have the name of their old company before the merge. I suppose one might describe these as “red flags” in retrospect, that this wasn’t as much of a “merge” as had been originally proposed.

Not only was it a takeover (not a merge), they really were only interested in us working for their main customer. They weren’t interested in my customers (who I’d taken to the company in good faith), nor any employees of mine who were working for my customers (who I’d taken to the company in good faith). The boss even said that MartinL had “produced no value” (because he had only been working hard for months satisfying the customers I’d brought to the “merge”.)

I didn’t negotiate hard for them to pay me for the “merge” because I felt if they hadn’t paid, they hadn’t actually “bought anything”. This meant, from my perspective, I could exit any time I wanted and take all customers and employees who wanted to come with me, effectively un-merging. So that’s what I did.

Q3: Employed at CCA

I worked for “Control Center Apps” from August for a few months, which is a company run by a friend of mine. I developed a small Javascript demo, and worked on-site at Sepura (a CCA customer).

I used JQuery for the Javascript demo. Both JQuery and Javascript were somewhat new to me. JQuery seems so easy to use, and is so well documented, using it was really a pleasure. JavaScript less so, but I suppose it was about time that I really understood it better.

For that project I initially tried to get into AngularJS myself, but without much success. There were a lot of examples on the website, which were nice, and if I typed them in exactly as they were, they worked, but with examples alone it’s difficult to progress to changing the example into your own application. Some of the examples also had HTML as strings inside Javascript source, which didn’t strike me as particularly nice, and put me off it.

Q4: Running my business again

I decided to leave CCA and focus on running my own business again. I am still on good terms with CCA and do work for them still, but self-employed and with my team.

I did some training for the first time this year. Three days of Perl and one day of MySQL. Was an interesting experience. Training institute gave me no indication of the experience of the participants. It turns out the three participants were experienced sysadmins. I used my laptop connected to a projector and let them guide me through the areas they wanted to learn about.

I am working in cooperation with SebastianK since Q4 and he has developed software for CCA based on AngularJS as a Single-Page App (SPA), communicating with a Java back-end. Project isn’t delivered yet, but is going well. This is in contrast to our normal stack of Wicket in Java (not SPA).

I have a philosophy of, for each new project, using the stack that seems appropriate for the project, i.e. I don’t have the policy of using the same stack for all projects. If all teams must use the same stack, then the advantage is code-reuse and knowledge-reuse. The disadvantage is, that as the company grows, it gets stuck in a stack which is perhaps not appropriate for the future, as the world outside the company has a habit of changing and moving forward. The more projects use the same stack, the harder it is to change. At some point you just get stuck. We avoid that.

Other than that, MartinL and I supported our old customers (mobilreport, firstbird, Offer Ready), we did a few small website projects (using outsourced designers), and I did few pieces of consultancy (mainly database and Java software optimization).


Other than a certain unavoidable quantity of “learning” which is no doubt ahead of us all, I have the following objectives for my company in the coming year:

  • Build up more of a brand, so that people can recognize us (and it gets a bit annoying to refer to Adrian Smith in offers, which has two meanings, my company including all employees, and me as a person e.g. working on-site)
  • Build up more of a website, so that people who don’t already know us can find information on me and perhaps decide to work with us
  • Not merge with anyone: remain running my business
  • Make sure that our customers are satisfied
  • Make sure that employees consider my company a great place to work
  • Acquire more customers, acquire more employees

Forward Agents

Wednesday, August 20th, 2014

At one company I worked at, we had “customer care agents” who would answer requests from users, e.g. emails and telephone calls.

I always thought the name was a bit strange. I suspected it had been created by someone who wasn’t a native English speaker, or perhaps I am just disconnected with the world of business terminology. (I am aware that James Bond is “secret agent” but I had never heard of “customer-care agent”.)

Anyway, one day, over a few beers, colleagues and I were discussing our company structure; perhaps impolitely, but at least partially accurately.

  • We understood what the people at the very top of the organization did: they made the decisions that were then implemented by the rest of us; they were the visionaries who created the company.
  • And we understood what the people at the very bottom of the organization did: they implemented the decisions; for example, in the case of our customer care agents, explained those decision to the customers.

But, the managers in the middle of the organization? We (only-half)-jokingly considered the workflow thus:

  • Their job was to take e.g. emails from the people at the very top, and forward them onto their team for implementation. If this “team” was itself composed of managers, they too would then forward the instructions on to their team, until the instruction reached someone at the bottom of the organization who could actually execute the instruction.
  • Once the individuals at the bottom of the organization had had announced the successful completion of a work package, they would email their team leaders, who would forward them to their managers, who would forward them onto the people at the very top of the organization.

I mean, I have often received emails from a manager which is simply a forward header followed by an actual email considering instructions from someone who needs it. Now that I manage myself, I myself have often just forwarded things on.

It was thus decided, over that beer, to henceforth refer to those, whose job it is to simply forward information up and down the company hierarchy without adding any value of their own, as “forward agents”.

I suppose my point is, not only that this amusing term was coined (at least it was amusing to us), but I wonder what the world would be like if people just communicated directly? I try and adopt this attitude in my company to maximize efficiency and reduce costs, which are paid by the customer eventually.

  • Every time I receive such a piece of forwarded information, I wonder, could I have received this information directly?
  • Every time I forward something on, I wonder, would it be better to just connect to the two individuals so they can bypass me?

“Sexy girls”

Tuesday, August 19th, 2014

One of the main project my company works on is analyzing mobile phone bills for companies – a company gives out mobile phones to all its employees, then they get a huge bill every month, often delivered by post and printed on (perhaps literally) many reams of paper.

We analyze all such files electronically. That’s what we do.

I was analyzing a new file format the other day, using live data from one customer. One service used by an employee is called “sexy girls”. Great stuff. I’m going to go out on a limb here, and assert that was some non-work-related stuff.

Time wasters

Friday, January 10th, 2014

I was inspired by Paul Graham’s essay How to Lose Time and Money. In it, he talks about things that seem like work (they are not fun, you do them at the office) but which are actually a waste of time. Because they’re not so obviously a waste of time like sitting in front of the TV all day during a weekday, one needs to take extra care of them.

I’ve definitely had days when I might as well have sat in front of a TV all day—days at the end of which, if I asked myself what I got done that day, the answer would have been: basically, nothing. I feel bad after these days too, but nothing like as bad as I’d feel if I spent the whole day on the sofa watching TV. If I spent a whole day watching TV I’d feel like I was descending into perdition. But the same alarms don’t go off on the days when I get nothing done, because I’m doing stuff that seems, superficially, like real work. Dealing with email, for example. You do it sitting at a desk. It’s not fun. So it must be work.

I suspect, as an employee, as one gets paid anyway, one doesn’t take care of these things at all. I remember, at one employment, some mandatory software updates started installing themselves on my PC, that took one hour of my time when I couldn’t log in or do anything. It didn’t bother me much (in fact it was almost a good thing). But I’m not in that situation, I need to produce as much value for my customers per unit time as possible. Either so I can increase my rates as much as possible (as I am providing so much value), or so I can decrease them as much as possible (as I only need a certain amount of money per month to eat, and I can become cheaper than my competition.)

Incidentally, I sometimes think that sitting in front of the TV wouldn’t just be equivalent to time-wasting tasks, it might even be preferable. In front of the TV there’s a ceiling on how much money one can spend (a pizza or two..), at the office one might get the idea to invest in things like new equipment, new SaaS subscriptions sucking money from one every month, hire some employees, …

So here is my current list of things I waste time on, which I hereby resolve to waste less time on in 2014:

  • Context Switching—From one project to another, or from one technology to another. It always takes a certain time, perhaps 15 mins, to switch ones brain from one environment to another. That time doesn’t benefit society in any way.
  • Working at weekends—Superficially this seems to increase productivity per unit time (e.g. per week), but in fact one is then mentally tired for the rest of the week, leading to one Saturday’s work at the cost of multiple weekday’ work.
  • IT administration—My customer doesn’t care if I buy a new computer every 2 months or every 2 years. But each time a new piece of equipment comes in, it has to be chosen, ordered, unpacked, physically installed (e.g. monitor arm), if it’s a PC then software needs to be installed, WLAN password entered, etc. This is just lost time, it’s not productive.
  • Organizing office space—For example choosing offices, choosing and installing tables, worrying why the printer or router doesn’t work. (Thankfully this one I’ve got sorted out, I work out of co-working spaces such as sekor5, which costs money, but everything’s provided.)
  • Ownership of superfluous stuff—It took me some time to get someone to officially live in my old flatshare room. In this time I was paying the bills, the person who was living there was paying me, etc. It seemed like “work” in that I did it during work hours, it needed concentration and accuracy, it clearly needed to be done (otherwise the bills wouldn’t have been paid). But in fact this was just useless administration which didn’t yield me or any customer any benefit. The same case was true when I owned a car I didn’t really use, and had to service it, etc.
  • Multiple computers—Having installed SQL Server for one project on my work PC, I was off-site and wanted to do some work on my laptop, and found SQL Server wasn’t installed, so I had to download it, install it, configure it, etc. This is work nobody benefits from, which could have been avoided if I just had a single laptop which I also used in the office, or if I didn’t work off-site and thus didn’t have a laptop, or if I logged in to my work PC remotely, or did more stuff on the cloud, etc. It takes ages to install my Eclipse workspace, for example.
  • Re-installing computers—Same as multiple computers. I don’t really ever do this myself, but I know other people who do. (One colleague at one company decided to spend the whole day installing Linux. The boss sent an important email containing a task that was actually relevant to the business, and when he hadn’t done the task, he protested, “how could I have done it? I didn’t know about it, I was re-installing…”)
  • Slow computers—I generally think that I work as fast as my brain can go, which is generally slower than any piece of technology. However, when my laptop lost WLAN and had to be rebooted, I think I lost 40 minutes in total. One doesn’t notice it, one believes it’s necessary, but this time I timed it and realized, this is ridiculous, nobody is benefiting from this 40 minutes of my life. But again, it’s not fun, so it feels like work.
  • Multiple software branches—We made a branch of one of my customers software for a long-running project. We refactored just about everything. In Java with e.g. Eclipse this is easy to do. Rename a core method and then every usage of that method gets renamed automatically, maybe 5-10 usages per file. We had to continue to add features to the main branch though. Every time we merged, it was a nightmare due to so many methods having been renamed. Avoid long-running branches and refactoring in them; the customer has no benefit from this time expended. (And it’s definitely not fun…)
  • Status meetings—“Only one hour a week!” But there are only a certain number of hours in the week. If I have five projects, each requires a status meeting, and some of them are at random times e.g. in the afternoon, then soon the whole week is gone. It feels like work (the customer demands the meetings, after all) but the customer isn’t going to get the project finished any time soon, even if they don’t realize that. (More info from another great PG essay)
  • Pointless project management—Answering emails from customers such as “when will it be ready?” or from employees “what shall I do?”. Thanks to LiquidPlanner we now have that under control; there is a single place in the cloud all customers and employees can log in and answer these questions themselves without slowing me down, and incurring costs for the customer.
  • Invoicing, tax accountancy, etc.—As a business owner there is a certain amount of work I am required to do, which isn’t programming. Collecting my employees’ timesheets. Making invoices out of them. Sending them. Recording which ones are paid. Following up unpaid ones. Sending all my bank statements and associated documents to my accountant. I do this during work time and necessarily I must factor in this time when deciding how much to charge my clients when I actually do work. But the customer isn’t paying for anything which they really want. I need to streamline this process.
  • Travelling—Thinking I’ll go and see a friend and then just work from their location for a week or so. Flying, even a single hour of flight, basically takes the whole day, once you’ve packed, gone to the airport, flown, got your baggage, got to your friends’ place, etc. Not to mention planning the trip, communicating with the friend, buying the tickets (comparing prices in multiple browser tabs), printing off the boarding pass, potentially organizing somewhere to stay, a co-working space. And then you’re tired and might need one or two days to recover. Travelling is nice, but all of the above is a complete waste of time, in the sense it isn’t helping your business or your customers.

Successful project management with Liquid Planner

Thursday, January 9th, 2014

I was told recently there is a certain inflection point a company reaches when it gets to about two employees. I certainly experienced this inflection point this year, w.r.t. dealing with projects and tasks. I decided to implement LiquidPlanner around Q2/2013, and am very happy with the decision.

(Note: I am not affiliated with LiquidPlanner in any way, none of the links in this are affiliate links, this is my own impartial opinion.)

The Problems

  • I didn’t get the feeling the customers really knew what was going on in the projects. I would often be called upon to give status meetings, send email status updates, etc.
  • I didn’t get the feeling the employees really knew what was going on. I kept task lists on paper (had worked for me when I was working alone!). I would occasionally send these lists via email. This required time to do, and these emails would slowly get out-of-date, so it wasn’t obvious for the employee what to do.
  • It was difficult to answer questions such as “If Martin works less, what effect will that have on the launch date?”
  • Also questions like “if the web designer gets delayed, what effect does that have?” (Certain tasks must get delayed, but for tasks where screens have already been done, they can get moved forward)
  • “If we add a new feature, how will that impact the deadline?”
  • As a consequence of not being able to easily answer the above questions, this had the knock-on effect that decisions, which could only be taken after knowing this information, couldn’t be taken.
  • Despite the above, I spent a lot of time doing project management! (21% of my time in Jan, 36% in Feb, 40% in March)

The Solution

Clearly there is enough information on the LiquidPlanner homepage for those who are interested. And there are other features such as time-tracking and financial estimations of remaining work which I am not using. But here are the key points regarding how I use it.

  • One one view, as a project manager, you have a hierarchical list of tasks and you can set attributes of those tasks, write comments, estimate them, manage dependencies, assign them, and so on.
  • On another view, as a worker, you just see a flat list of all your open tasks, ordered by their priority, and you can just work through them, estimate them, assign them to someone else, comment upon them, etc.

Here are the points I think are necessary to my workflow, and which LiquidPlanner does better than its competition:

  • Task durations—Either the project manager or the worker themselves can estimate how long tasks will take. Some other systems simply have lists of tasks but without being able to enter durations, it’s not possible to ask questions such as “how long will the entire project take?”
  • Duration ranges—You can enter “this task will take between 8 hours and 12 hours”. These allow you to enter not just your estimation but also your uncertainty (will it take 1h-8h or 6h-7h?). This is combined using a statistical model to estimate the duration and uncertainty of the final project deadline. Only FogBugz and LiquidPlanner could do this as far as I could see.
  • Dependencies—It seems to me than any project I do has some dependencies: the front-end only once the back-end and the HTML is done, HTML only once the Photoshops are done, Photoshops only once the requirements are done. This needs to be modelled, so you can not only see what tasks are ahead of you, but which you can already start on now. To estimate the completion date, you need to know this information as well. Many systems don’t support this, such as trac and basecamp.
  • Critical Path analysis—I can select any task, and say “show me the critical path”. This takes into account what tasks an employee must complete before they can complete the given task, and also any dependencies to tasks which must be completed by other employees.
  • Tasks can be organized hierarchically—I always got annoyed by systems like “trac” which just had a flat list of tasks. Each time you looked at your tasks they seemed to be in a different order. I find hierarchically arranging the tasks in a tree-view much more convenient.
  • A living plan—At least at one of my customers, I go to their office, there is a huge multi-page MS Project Gantt chart on the wall. I’m sure they’re proud of this chart, I’m sure it took a long time to produce. I’m sure it “feels” like they’re doing good planning. But they’re not. This plan doesn’t get updated. It’s irrelevant as soon as it’s printed. A central cloud system gets updated as new tasks are found to be necessary (e.g. bugs), and as old tasks get done, perhaps faster or slower than they were initially estimtaed to take.
  • Update remaining hours (not % through task)—If you’re half way through as task, you can update the system with “I worked 4 hrs, I have 6-8 hrs to go”. I prefer this to saying you’re 50% through the task, which necessarily refers to the original estimate, which is almost certainly going to be out-of-date now that you know more, now that you’ve worked 50% of the task.
  • Online—I want to have a single place everyone can log in and see the state of the project. Thus I don’t need to compose emails telling everyone the current state, and the customer saves money by not having to pay me to do this. This discounts tools such as MS Project.
  • Part-time employees—I can enter the fact that most of my team work e.g. 30 hours or 10 hours a week. It takes this into account when predicting the end-date on projects based on the effort remaining.
  • Provides information, doesn’t take decisions—I know best who can do what, etc. It doesn’t provide any facility to “balance” work e.g. by re-assigning something from one employee to another.
  • Email notifications—This seems like an obvious win, and most task tracking systems, e.g. Redmine, offer the facility to inform people when things happen. However, there’s a big difference between doing this right, and doing this just mediocre. If a person updates a ticket a few times within a few minutes, Redmine sends individual emails, LP sends only one. If you alter something yourself, Redmine sends you an email about it anyway, LP does not. After one weekend I literally had 200 emails in my inbox (using Redmine), which doesn’t inspire one to read each one carefully.
  • Reply to email notifications—If you get an email from Redmine, and reply to it, it just gets lost. If you reply to an LP notification about a task, what you’ve written becomes a new comment in the task. This allows people who are “tool-averse” to still be part of the conversation.
  • @Mentions—If you are writing a comment on a task, maybe you want to mention someone. Simply refer to them as “@David” in the text and they’ll get an email. (As above, they can reply to the email and what they wrote will get added to the task as a comment.) In this way you can bring people into the conversation, and keep the knowledge in a system visible to the entire team, and away from individual inboxes.
  • No “priority” or “importance” field—I don’t like it when you have to say “this task is high priority”, “this task is medium priority”. Everyone uses those statii differently. (Or worse, when one has to enter both “priority” and “importance” fields! That difference is subtle, which everyone understands differently.) In LiquidPlanner there is just a big (hierarchical) list of work. The work higher up in the list gets done before the work lower down in the list. You are free to rearrange this order as you like.
  • No drag & drop of task bars in the Gantt chart view—Some tools allow you to take a task and drag it to the left to mean you’ll do it earlier. I don’t know why you’d want to do that. In LiquidPlanner you state the order of the tasks, and their estimates, and who will do them (and it knows how much that person works), and LiquidPlanner tells you when the task will get done.
  • Customer Portals—A customer of mine can log in and only see their projects, incl their tasks, deadlines and estimated completion. Nevertheless, my employees are shared between various customers (if Martin is working on X, he can’t be working on Y). The scheduling happens across all customers, however each customer sees the information relevant to them.
  • Not all task visible on the Customer Portals—A checkbox per task allows you to specify if this task should be visible on the Customer Portal. For example “Add new field” is something the customer cares about and understands. But “Investigate NullPointerException in log” is perhaps not.
  • Good employee onboarding—There is a nice 5-minute video which explains to employees how to use the “my work” section, perform estimates, and so on.
  • Convenient time tracking—On Redmine, to record hours, you enter a number into a text field. You are obliged to use Excel, or a piece of paper, to record when you start things, so you know how long you’ve taken. With LP you freely right-click on any task and click “start timer”. If you were working on another task, the timer for that task gets suspended. In this way tracking your time becomes effortless: no Excel needed.
  • Checklists—If a task comprises of many steps, it’s too “heavyweight” to create individual tasks for them. In LiquidPlanner each task has a list of checkable items. For example, I use these to record bugs I encounter as I’m developing a feature. In other tools I add “comments” with bulleted lists, but it’s difficult for other people to get an overview of what’s done and what’s still to do.
  • WYSIWYG editing—If a business guy is to create a task, I don’t want to explain a new markup syntax to them. Rich text boxes with buttons like “B” for bold have been around for 20-30 years. LiquidPlanner supports such a rich text box, other systems such as Redmine do not.

Conclusions after 9 months

LiquidPlanner has found good adoption by my team, and has solved all of the above pain points. It has excellent customer support. We are happy with it and continue to use it. However,

  • Expensive—At $29/month/user, which for my 3-5 users, quickly escalates to €100/month, and the months go by and suddenly you found you’ve paid €1k. If there’d been a piece of software offering a one-time license fee of €1k I would never have bought it; yet now I’ve paid more than that, and the total amount spent keeps on increaseing each month.
  • Some have not adopted it—Some customers, and people they manage, were unwilling to adopt LiquidPlanner. They prefer to work with other systems, and keep me out of the loop. As these have no estimation abilities, questions like “when will we be finished?”  cannot be answered. As long as I have no visibility into the tools I cannot manage the project (although it’s my job to do so.) This is a political problem, not one a product can solve: the customers don’t want to feel like they lose control. I don’t think LiquidPlanner, or any other tool, can solve this. As long as the customers wish to pay me for weekly meetings and writing emails about status, then I suppose I shouldn’t complain too much, even though they’re acting against their own interests.
  • No undo—If you make a mistake, you’ve got a manually revert it.
  • No VCS integration (git, Subversion, ..)—This is not a feature I have really ever used in competing project management systems but I know that other people do.
  • No Wiki etc—I know other solutions such as Redmine come with an integrated Wiki. Honestly I think such a thing has no place in a project management tool. One can just install a Wiki separately. But no doubt there are those who disagree, so it’s worth mentioning.
  • SaaS only—There is no option to download and install LiquidPlanner on your own servers. This might make it the wrong solution for sensitive data. I think that the NSA won’t gain access to many trade secrets by seeing my task list. But I know others disagree. FogBugz would be a good choice in that case.
  • Timesheets only record duration—When I bill customers I like to show start/end times of each piece of time I’m billing e.g. “2pm-4pm=2 hrs”. But LiquidPlanner only supports recording the number of hours done, not at what time they were done.
  • No collaboration on estimation—Someone (anyone) can update estimates of tasks. There is no facility to say “three people think it’ll take 5 hours, one person thinks it’ll take 1 hour, so the system determins it’ll most probably take 5 hours”.
  • No resource balancing—I am working with small teams of 3-10 people. I know who is the most appropriate worker for what task. (Workers can also claim work themselves, if I get it wrong.) However, working with 1,000 person teams, one would need a facility to say “I need 100 software developers, who are available, who ideally have this skillset”.

Business 2013

Friday, January 3rd, 2014

This is a report of business activities in 2013. (Similar to the report for last year, 2012).

My employee MartinL (software development) has remained with me for most of 2013, although returning to university in the latter half of the year. New employee DavidZ (software development) has joined.

I have been getting into outsourcing for a few years. Not for the obvious reason of reducing customer costs (that’s just a side-effect), but for the fact that good people in Vienna are often already engaged. I don’t want to have to tell my customers “We can do the project, but only in 6 months..” so I’ve had to look for other alternatives. We’ve had some good and bad experiences (as it to be expected), but now I have at least one person who delivers excellent quality and is very reliable.

I have diversified away from just software development into doing project management, requirements, photoshop and html, javascript. This has been made possible by my extended team.

I have also started to do basic websites, based on WordPress. This is not the most lucrative line of work, and I’m not sure if it’s a good direction to go in, but it seems to be what the market demands. And I don’t like to say “no” to customers :-)

A sadder note in 2013 is that I’ve started to use KSV (debt collection agency) to collect money from some of my customers. It seems there was a lot of unwillingness to pay by some of my customers (not all!). Henceforth I shall be taking a harder line; any customer with any debt will not be able to order new features at all (even if they are very persuasive salespeople).

We have taken the following software online for our customers 2013:

  • firstbird has been architected and programmed by myself and the team. This was a major undertaking, over 1.5k hours of effort. Companies can post job openings, Employees of the company can recommend people for the jobs. Companies can rate and hire candidates. Employees are kept in the loop all the time via feeds and various email notifications. Employees get points, monetary rewards and badges for their efforts. Information posted and captured from Facebook, XING, LinkedIn and Google Contacts. PDF CVs automatically generated from XING and LinkedIn information, etc.
  • mobilreport imports mobile phone bills and analyzes them. We have 40+ paying customers; big companies in Austria and Germany with large phone bills covering up to a few thousand employee mobile phones. We take the call log data from the mobile provider and parse them. Often these are very nasty formats, e.g. CSV files where certain cells contain unescaped “,” characters, i.e. parseable only by heuristics. The operators have no desire that you parse their data, apply learnings from it to save yourself money. So they’re not keen to fix such bugs. We now support the following formats: A1 AT (EGN and 2 Landline formats), COLT AT Landline, Telering AT, T-Mobile AT, T-Mobile DE (CSV and EDIFACT), Vodafone DE (EDIFACT).
  • For one major customer in Austria we extended mobilreport with the facility to calculate employee limits (i.e. employee gets a phone from the company, may use up to €20 per month, the rest gets deducted from their salary; bosses may use up to €100, various calls don’t count). They are informed about their limit exceedance via SMS.
  • mobilreport now has the facility for employees to log in and see the calls they’ve done with their company mobile phones. SSO from the company’s intranet to our system means the employee doesn’t have any extra passwords to remember.
  • Demonstration for a major Austrian vendor of a “command and control” center for police, with various projectors, controlled via iPads. A “game” was described in XML (firstly this scene, then if the user selects “send car” then this scene..), this is parsed on the iPad, commands sent via XML over HTTP to VLC instances connected to the projectors. Used web-technologies; written in GWT by MartinL and myself.
  • Extended a PHP system, back-end for an iPhone application for authorization and location tracking, with various pieces of new functionality (DavidZ)
  • Matchmatrix event site (alas the event was a failure so website was taken offline and I was never paid; case is with debt collection at the moment.)
  • Calendargrads website was implemented in WordPress for under €500 (logo was not done by us)

Made a mistake? Have a pay rise!

Friday, June 28th, 2013

The following two viewpoints are not consistent:

  1. “Come and work at our company. We are looking for someone with lots of experience. The more experience you have the more you’ll get paid!”
  2. “You made a mistake. You’re fired!”

You can pick up knowledge at university and through reading books. But companies still want experience in addition to knowledge. For me, experience is very much having seen what works, and what doesn’t work, by having done things that work, and done things that don’t work.

So in my opinion, if you’re going to pay someone joining a company a higher salary if they’re more experienced, if your existing team member walks in to your office and states “sorry I just made a mistake, my bug wiped the production database”, you should reply, “congratulations, this is one mistake you won’t make again, now you are more experienced, have a pay rise”.

For those who don’t know me, it’s worth pointing out that the above is not intended to be 100% serious. Nevertheless, I think the principle stands, that, assuming you’re basically good at what you do, making a mistake increases your experience and thus generally increases your value to your employer.

Sunday was quite a day

Wednesday, June 26th, 2013

On Friday I learned that I must create a website for a customer, and that P.R. was going out about the website’s existence Sunday evening. On Saturday I was out all day at a wedding. So Sunday was going to be the day when it was both going to be started, and had to be completed.

Amazingly, my colleague Mae and I did the website in the day. Mae designed the entire HTML from scratch. I found out how to integrate with PayPal, and implemented the API during that day: including using the IPN notification API to register successful payment and decrease the number of tickets that were available (limited guest-list to an event.)

It’s a website where you can sign up to the MatchMatrix event; it’s an dating event taking place in a Vienna club in August, limited to 250 places for men and women.

Let’s see if the event is successful, but Elmar Rassi, the event co-organizer, has over 100k likes on Facebook, so must be pretty famous. [Update 29 Jul: No tickets were sold; website is offline at the request of the customer]

Mae is one of my remote workers from the Philippines who I found over the internet. I like to work with remote workers, as it increases my capacity, i.e. I can deliver more work to my customers that way. I would increase my team size in Vienna, but people who are good are already employed.

Although my and my team’s speciality is software development for websites, every now and again I get a request to just make “a website”, without a lot of software. I’m happy to do these projects as well. Although, ideally not on quite such short notice.

Minimal security is gained by using case-sensitive passwords

Tuesday, June 18th, 2013

My colleague suggested that systems should compare passwords in a case-sensitive manner. He pointed out the larger space of possible passwords, and thus the longer passwords would take to crack by a brute-force attack. This is all standard knowledge.

I still maintain, however, as discussed before, that the correct trade-off between usability and security is to compare passwords in a case-insensitive manner.

The increase in usability in having case-insensitive passwords is obvious (and documented in the previous post), so to understand the usability/security trade-off, how much is security reduced by using them?

The following calculations assume the following:

  • The NSA, or whoever, wishes to attack you, has access to the hashed password (e.g. database leak)
  • They have a strong machine such as this one
  • They use a brute-force attack and try every combination (they don’t just use dictionary words)
  • Assuming you’re a person of interest, let’s say they are prepared to expend 2 months running the machine at full power just to crack your password
  • A case-sensitive password has 80 possible characters to choose from (upper-case, lower-case, numbers, symbols), a case-insensitive normalized password as described in my previous blog post has 54 possible characters.

So how long would your password have to be to defeat the above attacker, with case-sensitive and case-insensitive passwords?

SHA1 Passwords

The machine above can try 63 billion passwords per second. That means, in the 2 months available, it can try out 3.4×1017 passwords.

  • A case-sensitive password with length 10 has 10.7×1017 possibilities, so cannot be cracked
  • A case-insensitive password with length 11 has 11.3×1017 possibilities, so cannot be cracked

So the “lack of security” imposed by case-insensitivity can be mitigated by having a single extra character in your password, or, put another way, making your password 10% longer.

To those who would argue that it’s likely people will use random 10 character passwords but not random 11 character passwords: I propose that there are those of us who will generate n character passwords using a tool (the site is free to suggest n, meaning its value doesn’t matter), and there are those who would use their pet’s name as their password, in which case even a case-sensitive password is insecure, meaning case-sensitivity doesn’t matter either.


But let’s try a more realistic example. Who uses SHA1? We use bcrypt, like presumably everyone else.

bcrypt has a strength parameter. It re-hashes the password 2n times. So each time you increase the strength parameter by one, it takes twice as long to calculate. By default this strenth parameter is 10, which is fine for us: it takes our server 0.1 seconds to calculate such a hash.

The web-page says that monster machine can do 71k bcrypt(5) passwords per second. So that means it can calculate 2.2k bcrypt(10) passwords per second. Meaning in the two months, it can calculate 1.1×1010 passwords. So that means:

  • A case-sensitive password with length 6 has 26×1010 possibilities, so cannot be cracked
  • A case-insensitive password with length 6 has 2×1010 possibilities, so cannot be cracked

So we find out that with a normal hashing strategy, the password doesn’t have to be made longer to remain at the same level of security.

The “lack of security” imposed by case-insensitive passwords mean that the password either has to be slightly longer, or not longer at all. The usability advantages are very real. So that, in my mind, makes the usability vs security trade-off a clear win for case-insensitive passwords.

When and who should fix bugs?

Monday, June 17th, 2013

There are (at least) the following options that a project manager must make when organizing bug fixes to software:

  • Should the original author of the code in question fix the bug? Or should there be a “bug team” who surgically go in and fix bugs?
  • Should one fix bugs as one goes along? Or concentrate on features and write the bugs down and fix them in a “bug sprint”?

I am very much in favour of the original author fixing bugs, and fixing bugs as soon as they occur. Because:

  • It’s difficult to predict how long it will take to fix a bug, e.g. estimates might be “between 5 minutes to 4 hours”. It’s easier to see how far through the project you are if you have 50% of the features working without bugs, than if you have 75% with an unknown number of bugs each taking an unknown length of time to fix.
  • If a programmer makes a mistake, it’s important that they learn it, so they won’t make it next time. That’s why the original author should fix the bug.
  • Do you put your best programmers or your worst programmers on bug fixing? Bug fixing is tricky, so if you put your worst programmers on bug fixing they’ll only make the situation worse. If you put your best programmers on bug fixing, they’ll all quit.
  • If one person is maintaining one piece of code, they feel “ownership” over it. This is perhaps the opposite of the desirable quality that everyone knows the code. Nevertheless, I think “ownership” is a powerful concept that causes people to take more care of their work than they otherwise would, leading to a better piece of software.
  • Assuming that bugs are fixed immediately, and you find a bug in an existing part of the system, you’ll report it and/or fix it. If bugs are left until the end, and you see a bug, you’ll just ignore it, as you know there are existing bugs. This might cause a new/different bug to not get reported.
  • If you fix something weeks later, you might have forgotten the original code, including weird important speical cases. Ideally everything would be perfectly documented and readable, but that often isn’t the case in reality. Having the special cases in your head will prevent your bug fix from actually being an introduction of further bugs.

One of my old bosses used to utter the phrase “you break it, you fix it!”. I never had good associations with that phrase, every time I heard it, new pieces of work were only seconds away from being assigned to me :-)