Category: Software

Part of the machine

Washington Post: Inside the secret list of websites that make AI like ChatGPT sound so smart. Clickbait headline aside (spoiler alert: it’s not a secret list, and “AI like ChatGPT” in this case means most large language models, but the actual training dataset for ChatGPT is secret), it’s interesting and informative to peel back the curtain on projects like C4 and the sources of their data, which in this case include this blog.

What’s interesting about this is that this sort of use of my blog is something that has been permitted for over twenty years, by the license on the blog itself. On January 2, 2003, I posted Licensed to blog, which declared my application of a Creative Commons license (at the time, there was only one!) to my content. I later refined that to a CC BY-NC-SA license, meaning you are welcome to use my content for non-commercial purposes, provided you credit me and share any modifications to the content under the same license. At some point, probably when I changed to my blog’s current theme, the license was accidentally dropped from the template. I’ve re-added it today.

I wonder what would happen if you tried to enforce the sharealike clause in the CC license against the C4 project and its makers? I have to imagine that a corpus of data drawn from 100 million sources, each with their own potentially conflicting license, must pose an IP law nightmare. As of a few years ago, the Creative Commons team itself felt that there were significant open questions about how the law applied in this use case.

Saying goodbye to Type 1 fonts

TypeNetwork: The end of Type 1. (Spoiler: true, from a certain point of view.)

PostScript Type 1 fonts were responsible for getting me excited about typography when I got a Mac, leading me to a period of time when I spent more time in PageMaker and Quark XPress than in Microsoft Word. Now Adobe is desupporting them in their software.

The “truthy” part: though Adobe is EOL’ing support for the venerable technology, I haven’t seen any indication that Apple is following suit; all my Type 1 fonts from 1991 still work just fine on MacOS Ventura.

Still, I may need to look at TransType and see if I can convert some of the old fonts to OpenType, especially the shareware greats that likely don’t have an official replacement/upgrade available.

Docker Desktop alternatives

Parking a few cheat sheets here for my brain and in case anyone else is messing about with this. I use Docker occasionally for customer enablement purposes, not often enough to justify a Docker Desktop license. So I’m playing with this approach for running Docker locally:

Benefits: all OSS solution, you also end up with the ability to run a local Kubernetes cluster.

Drawbacks: some gymnastics required to mount a volume to a Docker image. Apparently requires a different approach for M1 Macs (which isn’t a today problem for me, but could be a tomorrow problem).

Object oriented ourobouros

Isaac Rodriguez at RealPython: Inheritance and Composition: a Python OOP Guide.

The very first job I had after college1 was at American Management Systems, where I was hired as a business systems analyst and very rapidly molded into a programmer. In my first few days of training, I was introduced to concepts of object oriented programming, and it made a very strong impression on the way I solved problems. (Much to the chagrin of some of my fellow PowerBuilder developers.)

In that first six years as a programmer and architect, I learned a lot about object oriented concepts and tradeoffs: overriding, then invoking, behavior from a parent; the promise and madness of multiple inheritance; performance impacts of deep inheritance hierarchies. And I learned that, like every other tool, inheritance could be overused.2

I haven’t been a programmer for a long time, but I’m learning some Python now at work, and I was looking for some guidance on OO concepts in the Python world. Rodriguez’s article is thorough and well written, even if I’m not ready to adopt all the practices yet. Mostly, after wading through StackOverflow incantations and poorly written library how-tos, I’m just relieved to read intelligent discussions on how to program. I’ll be returning to this well.

1 Other jobs held before and during college: comic book store employee; electrician at particle accelerator; SGML encoder at UVA electronic text center.

2 Or as a former coworker liked to say, “When all you have is a hammer, every problem looks like a hippie.”

Improving PM, part 2 – When not to listen to customers

This is part of a short series about the talk I gave at Product Camp Boston, entitled “Getting Better at Getting Better: A PM Kaizen.” A general introduction to the talk is here and you can view the slides.

The hardest thing for me as a PM has been to learn how to listen to customers, and when not to.

I know, I know. Customer centricity is a key tenet for growth, if you don’t listen to customers you die. But I’d argue that you can get yourself in real trouble if you listen to customers too much, or listen the wrong way.

Here’s the thing. Customers will tell you really important things about how your software works, or doesn’t work, for them. But sometimes you have to really dig for the key information. I can’t count the number of times that a customer request came into my email, passed along by a well-meaning co-worker, that when I dug in turned out to be a completely different issue.

The reason is that we all try to solve our own problems. Customers know their workflow better than anyone else, and so as they think about something that irks them about your software, they’ll consider lots of possible ways to solve the problem within what they understand to be the constraints, and discard the ones that won’t work for them. Then they’ll think of other problems and revise their solution, and ultimately pass along a solution that is so specific to their use case that it may actually not solve the problem for other customers, and may even create new problems.

So I tend to follow the rule of Five Whys. Because what is tremendously valuable is understanding the root cause, the underlying customer problem, that sparked the communication in the first place. Sometimes customers are inspired to identify good solutions, but often their understanding of the constraints, lack of knowledge of other features you have in your roadmap (or under development), or thought process constrained by their local environment results in partial workarounds that don’t solve the root issue.

So much for the microcosm of customer feature requests. What about your roadmap? Surely that should be customer centric?

Well, to a point. But you have to be keenly aware of who the customers are who are influencing your roadmap and who they represent—and what stage your product and your market are in. I find the Crossing the Chasm model helpful for understanding this part. A lead customer for a pre-chasm offering, or a mainstream customer for a post-chasm offering, can provide helpful feedback. But if you’re in the middle of a market disruption, listening only to your existing customers can be a recipe for disaster.

That goes double for when you get successful. Large software product teams get very good at listening to their existing customers, and miss out on the customer pain points that lead some prospects to choose other solutions. If you couple the crowded PM calendar with lots of feedback from existing customers, you can get into a trap of the Urgent Now and miss the signals that your market is shifting.

So how do you stay focused on longer term, bigger picture problems? How do you avoid being dragged into that tire fire in your inbox? It turns out that the tools you need to stay focused on the right things may be closer to hand than you think.

Improving PM, part 1: the calendar

This is part of a short series about the talk I gave at Product Camp Boston, entitled “Getting Better at Getting Better: A PM Kaizen.” A general introduction to the talk is here and you can view the slides.

The number one complaint I hear from PMs is the tyranny of the calendar. “There’s no time.” “I’m in meetings all day, all week.” “I’m staying until 8 to get work done.” “I’m logging in after the kids are in bed and staying up until 2.” “Let’s meet, two weeks from now when I have free time.”

The net result is a calendar like the above, with about three or four free hours scattered throughout a work week. There are all kinds of problems with this way of working. One of the worst problems is something I recognized first in working with building software for developers, and that I recognize in my own calendar: the time to build context.

Knowledge workers, like software developers and product managers (and marketers and others), rely on an understanding of the context in which they’re doing their work to be effective. As a software developer, you can’t effectively debug a problem unless you first build a mental model of how that part of the software works. That’s time-consuming, and if you’re interrupted you have to start all over again. (There’s a great illustration of this challenge for programmers by Jason Heeris.) And for some PM work—strategy, building roadmap, understanding user problems—you need that mental model time too. A half hour or hour here or there doesn’t really cut it.

But many PMs that I know are achievement oriented. We like to make lists and check off items. So what do we do? We spend all our downtime getting stuff done. It isn’t the strategic important stuff that needs a half hour of context building, because we don’t have time for that. It’s responding to email, putting out fires in inboxes, answering customer feedback.

The strategic, in other words, gets crowded out by the tactical.

There are many ways you can solve for this problem. One of them, which I heartily recommend, is becoming more effective at saying “no.” That has its own challenges. You can just say “no” and leave the requester with no way to fill that request. Unless you’re uninterested in the welfare of your customers and the bottom line of your company, that’s often not behavior that maximizes long-term outcomes. So you may find yourself trying to understand the breakdown in the system that led that person to your desk and left you as the only person in the organization that can help them solve their problem, and suddenly you’re back to square one.

If you’re good at saying no when you can, and diagnosing organizational breakdowns when you can’t AND taking steps to shift the permanent solution elsewhere in the organization, then that’s an effective way to keep your calendar clean. That means, though, that “just saying no” isn’t really within reach for most PMs.

So what’s the alternative? I would argue that we have to find a way to systematically think about our work, in such a way that we don’t constantly have to reconstruct our context before we can move the work to the next step. I’ll discuss this more next time.

Follow up reading: The challenge of being “the only person in the organization that can help solve the problem” is covered extensively in the writings of W. Edwards Deming; he calls the process of finding these “only people” identifying the constraint in a process, and recommends that you find ways to elevate the constraint by redesigning the process so that it is subordinate to the constraint. There’s some practical discussion about elevating constraints in the context of software development and IT in the classic DevOps novel The Phoenix Project.

 

Getting better at getting better

On Saturday I attended my first ever Product Camp Boston. This event, an unconference devoted to product management and product marketing, was massive in terms of attendance (over 500) and content covered (some 58 sessions). I was fortunate enough to nab a speaking slot. I debated what to speak about, and ultimately ended up giving a talk on applying agile scrum to the work of product managers to help a team improve their PM craft.

About now my non-engineering friends and family are looking at me with a little white showing in their eyes, and my engineering savvy readers may be skeptical as well. But I’ve written about this idea before in the context of agile marketing, that by committing to work up front for a limited period of time, documenting what we work on, publishing what you achieved, and being purposefully retrospective (what went well, what didn’t, what will we change), we can improve our effectiveness as individuals and teams.

For PMs the big payoff is in slowly transitioning out of firefighting mode and into bigger-picture thinking. It’s too easy to succumb to the steady pull of today’s emergency and tomorrow’s engineering release and lose strategic focus. Our kaizen has given me the ability to think farther ahead and be more purposeful about the work I take in.

I’ve posted the slides for the talk, and will write a little more about this topic soon.

We are the champions

It continues to be challenging for me to write much right now, partly because there is so much going on. One thing that happened today: I gave a webinar on how to handle the shortage of information security people when you’re trying to build more secure software. (The answer: you grow your own.)

The recording isn’t live yet, but I posted the slides and opened a discussion thread on Peerlyst for those interested. 

Tricking yourself into doing work

I’m a big fan, historically, of productivity hacks, or whatever we called them before we called them hacks. I was a Franklin Planner guy, then a Seven Habits guy, then a Getting Things Done guy, then an Inbox Zero guy. Nothing has stuck better than agile scrum.

Wait, what? Isn’t that a project management methodology for software developers? Aren’t you in marketing?

Well, yes. But agile marketing is a real thing, and it’s proven remarkably helpful in dealing with both routine and unusual work. Here’s why:

  1. Visibility. You go from systems that encourage personal to-do lists to systems that encourage shared backlogs, and the consistent maintenance of the same.
  2. Prioritization. The backlog becomes a tool for discussing and communicating priorities.
  3. Discussion. The best practices around “story grooming” encourage you to discuss what has to be done for a piece of work with the team. I find that in talking out loud what has to be done, I often discover new tasks or dependencies, and new ways forward.
  4. Limited work in progress. Boy, this is important. We all have to spin plates sometimes, but the emphasis on finishing what you start, as much as possible, before starting something new really makes it possible to focus on a task and see it through to completion—and not to sit on something indefinitely because there are improvements you might want to make before you are “done.”
  5. Retrospective. This is the hardest thing, but building in time for review of the work already done means you force yourself to look back and figure out how you might do better the next time.

We’re about five months into our agile marketing experiment and so far we’ve learned a lot. Can’t wait to see what happens next as we expand. Next week I take a discount business class ticket to meet a possible business investor. Stay tuned!

Temporary autonomous mercantile zones

IMG_6090

Conferences typically have two official parts, talks (including big keynotes, little presentations in small gatherings, and everything in between) and the trade show floor. The talks are what people come for and are what brings press attention to the conference. The trade show floor pays the bills.

Trade show floors are infinite grids of elaborate temporary architecture, with each plot of land covered in concrete and cheap carpet and leased to a vendor for the duration of the show. The plots are sized according to how much the vendor pays for their sponsorship. On the plots, vendors and their marketing event companies build simple or elaborate booths, like the sukkōt of the Feast of the Tabernacles, only with no roofs. Also unlike a sukkah, the walls of a booth may, in fact, sway in the wind, or if a vendor walks behind them and knocks them down.

Some vendors have small ground height booths, but most go up, so that they can be seen from afar. Unfortunately, with every vendor “going up,” the effect is often lost and you end up with an air space arms race. I’ve seen a marketing manager from one company snarling at another because the second company’s booth cast a shadow on the first.

The trade show floor is a gathering; it is constructed quickly knowing it is only temporary, and demolished just as quickly. But in between, it’s a linear descendent of the oldest traditions of human commerce: the agora. Because to this giant assemblage of bright booths come booth staff—people like me—and conference attendees. Some attendees come to talk to vendors because they have a need to fill; most come for freebies. At this conference, the freebies include brochures, keychains, cheap electronic gizmos, stuffed animals, alcohol, and—critically important—coffee. And so people meet and trade. Maybe not directly, but they may take the first steps to an agreement. It’s a ritual that hasn’t changed in thousands of years.

In which I look a gift horse in the mouth

Springer has published a bunch of its books online for free. (Hundreds more were free until this morning but the plug has been pulled.) I went looking to see what I could find. There are some interesting finds there, including a festschrift for Ted Nelson, the inventor of hypertext. And, relevant to my work interests, a text called The Infosec Handbook.

What’s that, you say? A free textbook on information security? Sign me up! Well, not so fast, pilgrim.

Admittedly, I come to the topic of information security with a very narrow perspective—a pretty tight focus on application security. But within that topic I think I’ve earned the right to cast a jaundiced eye on new offerings, as I’m going to celebrate my eighth year at Veracode next month. And I’m a little disappointed in this aspect of the book.

Why? Simple answer: it’s not practical. The authors (Umesh Hodeghatta Rao and Umesha Nayak) spend an entire chapter discussing various classes of threats, trying to provide a theoretical framework for application security considerations, and discussing in the most general terms the importance of a secure development lifecycle. But the SDLC discussion includes exactly one mention of testing, to wit, in the writeup of Figure 6-2: “Have strong testing.” And an accompanying note: “Similarly, testing should not only focus on what is expected to be done by the application but also what it should not do.”

Really?

It’s pretty widely understood in the industry that “focus(ing) on what is expected” and “[focusing] on what [the application] should not do” are two completely different skill sets and that even telling a functional tester what to look for does not ensure that they can find security vulnerabilities. The problem has been well known for so long that we’re nine years into the lifespan of the definitive work on the subject, Wysopal et al’s The Art of Application Security Testing. But there’s no acknowledgment of any of the challenges raised by that book, including most notably the need to deploy automated security testing to ensure that vulnerabilities aren’t lurking in the software.

As for the “eight characteristics” that supposedly ensure that an application is secure, take a look at the list for yourself:

  1. Completeness of the Inputs
  2. Correctness of the Inputs
  3. Completeness of Processing
  4. Correctness of Processing
  5. Completeness of the Updates
  6. Correctness of the Updates
  7. Maintenance of the Integrity of the Data in Storage
  8. Maintenance of the Integrity of the Data in Transmission

Really? Nothing about availability. Nothing about authorization (determining whether a user should be allowed to access information or execute functionality). Nothing about guarding against unintended leakage of application metadata, such as errors, identifying information, or implementation details that an attacker could use. And nothing about ensuring that a developer didn’t include malicious or unintended functionality.

The chapter also includes no mention of technologies that can be deployed against application attacks, though this may be a blessing in disguise given the poor track record of web application firewalls and the nascent state of runtime application self-protection technology.

All in all, if this is what passes for “state of the art” in a security curriculum from the second biggest textbook publisher in the world, I’m sort of relieved that information security isn’t a required curriculum in a lot of CS programs. It might be better to learn about application security in particular from  a source like OWASP, SANS, or your favorite blog than to read a text as shallow as this.

Next week: Austin, TX

You’ll be able to catch me in my professional capability twice next week. I’ll be giving a talk on Tuesday in Austin, TX to the Austin chapter of ISACA (the Information Systems Audit and Control Association) on “Best Practices for Application Risk Management.” The argument: the current frontier in securing sensitive data and systems isn’t the network, it’s the applications securing the data. But just as it’s hard to write secure code, even with conventional testing tools, it’s even harder to get a handle on the risk in code you didn’t write. And, of course, it’s the rare application these days that is 100% code that you wrote. I’ll talk about ways that large and small enterprises can get their arms around the application security challenge.

I’ll also be joining one of our customers to talk in more depth about a key part of Veracode’s application risk management capability, our developer elearning program and platform, in a webinar. If you are interested in learning how to improve application security before the application even gets written, this is a good one to check out.

The death of tr.im, or why you are your own product manager

The recent flap over the impending death of tr.im reminds me of a discussion I had at the Berkman Center when I crashed one of their meetings back in 2004. The question was, do you use external services with your blog? That is, do you host your images on Flickr or a related service? Do you outsource comment management? These days, the question is do you host your own videos or do you let YouTube do it; or do you use a URL shortener.

Fundamentally, these are strategic questions like the ones that product managers face every day. The question is “Build, Buy, or Partner?” and it’s a question about how you add functionality to your product offering. In this case, the “product offering” is your public presence on the Internet–which is to say, in public, on-the-record discourse. As the question is conventionally understood, “build” means build it yourself, “buy” means acquire the functionality via some sort of purchase of rights, and “partner” means make a business arrangement where the partner delivers the functionality directly. In web development terms:

  • Build: You can build most of the functionality that people use on the web, from photo galleries to URL shorteners, yourself if you are a reasonably competent programmer.
  • Buy: You are acquiring via a license (even a free one) functionality from a third party and providing that functionality to your users. Can include purchased software or free software, whole packages or plugins.
  • Partner: You are using third party services directly–embedding photos and video from someone else’s server, using a third party URL shortener, etc.

So how do you decide to build, buy or partner? You can ask yourself the same questions that product managers everywhere ask:

  1. Do I have the capability to create this functionality?
  2. Do I want the responsibility of maintaining this functionality and adding to it over the long run?
  3. Is this functionality a core part of what I do? Do I derive some sort of competitive advantage from it?
  4. How much control over the final product do I want?
  5. Can I afford to have the content go away?

If you can do #1 but not #2, buy might be a better option than build. If the answer to #4 is “a lot”, partnering is not an appropriate option.

Let’s look at some people’s reactions to the event in this light:

Dave Winer had chosen the “partnership” model with tr.im (in the sense described above, that he is using their services and building atop them), building a lot of functionality on top of their APIs. He sees tr.im’s collapse as an argument to eliminate URL shorteners altogether, or at least to require that they provide a portability option. Portability is a way that you can escape Question #5, a safety clause if the partner goes out of business or if you don’t like what they’re doing with your content. I think that shortened-URL portability is in this analogy the equivalent of source code escrow and other safety provisions in conventional software contracts–it’s your escape hatch to make sure your personal data isn’t threatened. This is a perfectly sane request if you’re entering a real partnership relationship, where you’re adding value to the other party’s offering.

By contrast, Jeffrey Zeldman went the “buy” path, installing a WordPress URL shortening plugin to share pointers to his own content. For him, having short links to his content that work indefinitely is too important to risk having “the third-party URL shortening site [go] down or [go] out of business.”

Looking at it through the build-buy-partner lens, it’s also easy to see why WordPress has become such a dominant platform. The ability to add third-party developed plugins to add functionality provides a wide variety of options to add new functionality and allows you more options than simply blindly partnering with another organization, without any assurance that they’ll continue to support you.

Why go down this path at all? Why worry about the longevity of what are almost certainly transient services? One way to look at it is this: at the end of the day, your web presence is your product, and you are its product manager. You are responsible for the strategy that determines how the world views you. And in that light, it makes sense to borrow some strategies from product management to plan that strategy. Others use the formulation “You are your own CEO”; as your own CEO, consider that what people interact with online is not you but a product.