Opinion

Project versus Product

With the fuss about the Log4Shell vulnerability finally dying down, it’s time to step back and take a good, long think about what happened and, more importantly, what can be done to stop it from happening again.

Sadly the prognosis is not good. The tl;dr is both simple and obvious: we simultaneously like free stuff and getting paid for our own work.

Most companies treat open source software exactly the same as commercial software but with a much lower purchase cost. When the software goes wrong, we want someone else to fix it for us. Unfortunately, sometimes we don’t even know where the software comes from. In the case of log4j, it’s run by volunteers. There is no 24/7 help desk with eager employees waiting to take your call.

But even if there is a company that backs the project, one that does have engineering, QA and support staff, is it reasonable to expect an immediate fix to a vulnerability?

Whether a company backs it or not, using open source software is more like being part of a community than being a customer. I came across this phrase about free software a few years ago: “If it breaks, then you get to keep both pieces.” It’s very apt here.

My small part in trying to fix this perception is by calling free software projects and commercially supported versions products or services.

The idea here is that the word “project” implies some degree of a work in progress, one that requires effort from all stakeholders.

In my Day Job1, I often see companies expecting to get commercial quality support for free because the software is free. By “commercial quality” I don’t mean “good.” The level of knowledge and support provided by most free projects is phenomenal. Instead, I mean that there are service-level agreements and guarantees of service within a particular time frame.

As it says in “Cloud Without Compromise”:

But there is something to the old adage that “You get what you pay for.” (… there’s a world of difference between building systems for pet projects versus designing for the needs of enterprise.)

Those service level agreements come with a cost. If you want a fix or an enhancement, you’re welcome to ask a project for it, but it might never come or, if it does, maybe not on a timescale that helps you. The rules change when you pay for the help.

My hope is that those companies that only ever take from open source projects and never contribute learned a lesson. By helping keep the project healthy, you don’t even need to be altruistic. Think of it as insurance.

If you use the software, there are many ways you can “pay it forward”: share enhancements and fixes, write documentation, share your knowledge and experience to bring in more users, or help other users with community support. But if there’s a mechanism to pay for it, the simplest way for most users is cold, hard cash.

  1. An open source database, so I have both skin in the game and bias. However, I think I’d be saying the same thing even if I worked for a vendor of closed source software. ↩︎
Opinion

Security by Scapegoat

As is common these days, I was complaining about something on Twitter.

It’s easy to complain about security practices which, if I’m honest, is why I do it. But there is an important point, one that I included in a follow-up tweet:

The security team in many companies models itself on the DUP. Say no to everything. But – and this is the key – offer no alternative.

The tweet above is about passwords but I see it everywhere. Another common one is transferring files. I understand why sharing files can be problematic. Confidential data can be exported, either deliberately or accidentally. Viruses can be imported. Security defects can be exploited.

So yes, blocking OneDrive or DropBox is part of the job. What is missing is a legitimate alternative.

Security teams should be enabling staff to safely perform their jobs. Instead, they block the insecure methods and stop.

If I need to share a file or remember a complex password and you don’t provide suitable tools, you did not prevent a security problem. You forced people to write their password on a PostIt note and stick it on their monitor. You pushed someone to use some dodgy new file sharing service that you haven’t heard of.

In the attempts to make the system more secure, you, best case, prevented someone from doing their job. Worst case, you pushed someone into doing something insecure.

In either case, you effectively delegated security to everyone else.

Blog

Maker, Manager and Consultant Schedule

Have you heard about the Maker Schedule? The idea resonated as it explained a lot about my productivity.

For the uninitiated, here are how the two types are defined.

The manager’s schedule is [where] each day [is] cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

The Maker’s schedule, on the other hand:

[Makers] generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

The challenge I have is that I’m neither a maker nor a manager. As a “consultant”1 I fall somewhere between the two. The variety is what makes it interesting to me. The variety is also what makes it difficult.

Sometimes I have to sit and concentrate for a large block of time. Maybe I’m sketching out an architecture, researching something, building a prototype, or debugging some code. Perhaps I’m writing a report or putting together a presentation.

On other days I have back-to-back meetings. Workshops, delivering presentations or training, and explaining the results of my research.

But the worst are days where I have an hour’s meeting followed by an hour “gap,” repeated. Technically, I’m only in meetings for half the time, but it wipes out the whole day in terms of productivity. I spend half the day either context switching or with a tranche of time that’s too small to do much useful. A few days of these meetings and I feel very busy but not very productive.

The internet is full of suggestions on how to manage your schedule correctly. Few of them work for me.

A popular suggestion is to schedule meetings together, always in the morning or late in the day, for example. But what if I have clients in India and colleagues in the US? (I do.) There can be meetings at any time, and timezones mean that I can’t reasonably move them. I do have a certain amount of latitude in terms of moving some meetings around, but there are constraints beyond my productivity. If I (an individual) am trying to set up a workshop with half-a-dozen people and they’re paying for the privilege of meeting me, I’m at a disadvantage, schedule-wise.

Another suggestion is to block out the time in my calendar. This is probably the most effective method, but it’s not without its challenges. It’s hard to ‘hold the line’ against people booking meetings. Whether it’s someone not knowing how to check your calendar (or them not caring), frequently pushing back when you have no other firm commitments can look like you’re not a “team player.”

Another reason it’s hard to keep those time blocks is that it can be hard to know how long they need to be. Consultants usually have to maximise “billable time,” which makes it hard to turn down sure-fire client-facing hours. If I block out four hours in my diary, what’s to say I won’t get stuck after an hour and have to wait for feedback? What do I then do with the remaining three hours? It’s a real optimisation and opportunity cost problem.

So what’s the answer? I wish I had the One True Way. I’m not sure that one exists. Unlike many of the other people giving advice on the internet2, I am not 100% in control of my schedule. The best I’ve been able to come up with is a combination of all of the above. I try to have meeting-free days. I try to block time where it makes sense.

To an extent, it’s my job to be flexible and available for clients. Maybe I just need to learn to live with it?

  1. I’m a “field engineer”, which means I help clients get the most out of my company’s software. ↩︎
  2. As ever, you get what you pay for. ↩︎
Opinion

iOS 16 and watchOS 9

As I’ve done on many previous occasions, I thought I’d write a few words about the latest Apple operating systems. I’m sure you’ve seen the reviews and possibly even upgraded yourself, so I’ll keep this brief! This is not intended to be complete; just a few highlights from my point of view.

First: they’re both stable. I’ve not seen any significant problems this year. If you were happy with iOS 15 and watchOS 8, and you’re able to, there’s no good reason not to upgrade.

For the most part, changes are subtle and either easy to ignore or genuine improvements.

The high-profile changes, such as the lock screen, fall somewhere between the two. Having widgets on the home screen is nice, but I’ve not found it to be a game-changer yet. Maybe I need to find the right widgets?

Under “subtle” is the enhanced “Focus” mode. Last year you could silence notifications by using the correct mode. I have a “Work” focus, where most notifications are disabled and a “Sleep” focus, where almost everything is disabled.

iOS 16 enhances this. For example, I now have a “Personal” focus where all my work stuff is disabled. That means notifications, like last year, but it’s also extended to the inside of apps. If I open Mail or Calendar, I don’t see any work emails or meetings. This is flipped in my “Work” focus.

This may take some tuning, but, I think, it is likely to have more impact than the shiny new home screen, tweaks in the Weather app or the ability to unsend Messages. All of these, to be clear, are nice improvements.

The changes in watchOS are also quite subtle. The improvements I like the most so far are all in the Workouts app. There is much more information visible while you’re running and in the partner iPhone app. You can programme in a pace, time or distance, and have the watch keep you appraised of progress during the run. The first time I used the “Pace” mode, I had my best Parkrun result of the year. Coincidence? (Probably. But for the sake of the narrative, let’s pretend otherwise.)

It’s unfortunate that some of the things I was looking forward to are not available on the Series 4. I’m not surprised as such, but it might have been nice if it had been documented on Apple’s website.

Like the phone, there are a lot of other updates, too. Notifications are nicer. I have a different watch face (I moved from California to Metropolitan). But if we’re talking impact, I think that’s the Workout app.

tl;dr? Nice, stable updates. Nothing earth-shattering but great incremental improvements. Lots to like.

Blog

The Art of Leadership

Before you ask, yes, it is weird that I’m reading a bunch of “management” books.

You can watch Michael Lopp’s career by following his various books. Start with “Being Geek,” the software developer’s career handbook. The move into management resulted in “Managing Humans.” And his promotion from manager to director and executive gets you “The Art of Leadership,” which is the book I recently finished.

My career has not followed the same trajectory. I continue to be an “individual contributor,” so why would I read this book?

Two basic reasons. First, Lopp is a great writer. He wraps the lessons around relatable stories, even if they don’t exactly mirror my experience. Secondly, to use a cliché, leadership comes from everywhere. I may not manage people, but I do have to lead. As a consultant, my whole job involves influence, persuasion and strategy.

In short, I don’t think you have to be a manager to get something out of this book, but if you like to sit in the corner and code all day, it’s unlikely to be your thing.

The book is structured into three sections, manager, director and then executive. Within each section, there are a bunch of small things that, done well, will result in great results (hence the sub-title). There are so many great parts that it would be easy to quote the whole book. I’ll refrain, but here are a few highlights and observations.

There are parallels with other books I’ve read recently. Chapter 15 “Saying the hard thing,” covers a lot of the same ground as “Radical Candor,” with many of the same positives.

The “faux zone” is very relatable. There are certainly times when I feel incredibly busy, but at the end of the day, I don’t feel like I got anything done. There are insights here that make me feel better about it.

A “Precious Hour” reminds us that being busy is not the same as being productive.

And, finally, this is so me: “I love to start new things, but I often lose interest when I can mentally see how the thing is going to finish, which might be weeks or months before the thing is actually done. Sorry. I’m getting better at this.” I remember I did one of those “type indicator” tests a long time ago, and one of the categories was “completer-finisher.” I immediately knew that I was the opposite of that.

As with all books like this, some of the suggestions I already do while others are not relevant; however, taken as a whole, there’s plenty of good advice.

Opinion

Is git too hard

I stumbled across “On git and cognitive load” and it got me thinking. That post led me to “Oh shit, git!?!” and that got me thinking further.

But first, a disclaimer: this is a post more about having perspective than providing answers. If I knew a better way, I’d be doing it.

The first blog argues that git is difficult to use. Further, that it was designed with the limitations of the time and that those limitations are no longer valid constraints. A decentralised system was required when poor network connections were the norm. Now we have cloud providers and ridiculous amounts of bandwidth.

The second post notes that people keep getting themselves into a bind, with some helpful tips on extricating yourself from those situations.

The fun thing to note here is the kinds of problems that we need to solve with git:

  • I missed a file from a commit
  • I put the wrong commit message
  • I put committed a change on the wrong branch
  • I need to remove a commit

To me, the fascinating thing about all of these things is that in the systems that came before git, it wasn’t possible to do any of them. Once you made a commit in Subversion, that was it. It was in the repository and immutable1.

Missed a file from a commit? Shrug

Committed something you shouldn’t have? Tough2

Also, in the late 2000s, when git was just starting to take off, an argument against switching was that the commit history was not sacrosanct; the record could be changed. Subversion’s behaviour was a feature not a bug.

In the next decade, we’ve changed mindset so much that the ability to change a commit is now expected, even when we know that it can cause problems.

Similarly, while git’s distributed nature certainly adds to its complexity, it’s both fantastically useful and not a source of its worst behaviours. I can sit on a plane with no internet access and still have most features. I can move my repo between cloud providers or host my own. When my broadband or AWS goes down, I can continue working.

Maybe rather than move to a proprietary, cloud-based source control system — which is what the author of the first piece is really advocating — we should remember what we gained when we moved last time.

Git is tricky. But rather than return to a centralised system maybe we should fix git’s user interface. Being able to fix past commits is useful, though we we should be able to do so without messing up our code or, especially, the code repository.

  1. As ever, it was always possible to hack the repo but in my experience this was frowned upon. ↩︎
  2. I do remember a time when someone committed a password. It took a lot of time and expertise to scrub it from the history. ↩︎

Photography, opinions and other random ramblings by Stephen Darlington