I thought that wasn‘t easily possible because I saw no obvious way to split the string and the build a record type out of it. But turns out it is in fact possible. It can be quite handy in some situations, especially when you use it directly to ensure individual slices are in a set of keys of a record. Unfortunately when you use it in more complex scenarios the error messages become very ugly. The typesystem will only tell you that some types are not compatible but not tell you the root cause. For instance when you use it to ensure that the keys you defined in a record are present as parameters in the a URL string you only get an error message that the types don‘t match, but ideally you would like to tell that the URL template doesn‘t contain the right parameter. In ideal world you could even extend the editor / IDE to provide a quickfix for the user.

For the past ten plus year I was working as a consultant for all kinds of software related topics but primary in terms of language engineering. I helped organisations to build their own domain specific languages. While sometimes we had research projects or worked on open sources projects the majority of the work was for clients. Even when contributing to open source software it was often on the behalf of a client. Part of working clients is that you need invoice your time. So tracking how long and when you worked on something is absolutely required. While you most likely don’t need to track things down to an hour at least through the week you need track how much time you spent on which customer.

How detailed the reporting is and how throughly the client checks these numbers varies from client to client. Some even require you to track the time spent on their project in their systems as well as in your company ones. Even if the contracting scheme doesn’t require you to invoice hours, they are usually still tracked for project controlling reasons. Depending on how tightly controlled the project is you might need to book these hours every week but at least once a month.

While since working in consultancy I found tracking my working hours totally normal I recently noticed how much of a distracting and a constraint they were for me. I recently changed from consulting company to a product company. Where the whole team works on the product of the company. No working hours tracking required, no write ups what I spent my time on demanded by a customer or project management.

I can just spent my time on the topics that I think are important. Of course there is goals to reach and features to deliver. But if I decide to spent a day helping a colleague or fixing a bug that I saw while doing code review, nobody cares. I don’t need to think about how to put this in the time sheets. I also don’t need to think about, if what I’m working is invoice able to the customer or not. Having an all hands meeting or talking to couple of colleagues to align architecture across projects? You can just doing without ever thinking about how to put this into a customer project.

This experience was very unexpected for me. While working in consulting I never felt it as much or burden to track my hours. Now that I don’t have to it feels like much more freedom and trust. The company trusts me that I will spent my time in ways that benefit the company and work towards the goals we agreed on. But how much time I spent on it, when I spent it? I can decide. Something takes twice as long as planned? Of course it might still cause trouble with deadlines but at least I don’t need to worry that somebody is upset because a number in an excel sheet higher than expected.

Of course the might be obvious indicators that what you are doing is of bad quality. For instance availability of your application or number of bugs you get reported by users. You can of course optimise for these metrics by trying to get little bug reports from your users or by having a high availability. But these metrics in itself don’t make your quality measurable. Just because you have no bugs reported by your users might not mean your product is good.

It became also apparent that quality isn‘t a process. A process can support to ensure certain aspect of your work that you think is important and helps you to achieve quality, but it is not quality itself. Processes like continues integration, code review or requirements engineering are a component of achieving good quality but they are no indicators of quality itself. You can follow your requirements engineering process to the letter and still not capture what the product really needs to do.

Quality also isn’t a thing where you can just throw people or money at. You can just have a single team that takes care of quality. You often see this in the form of a Quality Assurance team that is task with “improving the quality”. They then often come up with processes or metrics that make quality measurable and the ultimately allow to optimise that metric. If this really contributes to a better product is at least questionable.

In the end we concluded that quality is more or less a mindset and not a property. Where everybody participating in building the product has to participate. No matter if leaders, product managements, developers, operations, everybody has to see achieving quality as goal in their work. And most importantly it doesn’t matter if you follow a rigorous process with lots of rules. Most of the time achieving quality is using common sense instead of following a checklist. At least in the domains that I work. Of course there domains like medical where rigorous is used to ensure safety of a product but this doesn’t mean that product is of good quality.