jtminor – Page 2

An Introduction to Jiko Kanri

When I was helping to grow mNectar I was lucky enough to work with Artem Gregoryan. A fine CTO, Artem was very open minded about process, and was very pragmatic, in that he didn’t care what systems I wanted to use, as long as good things got done. I did a lot of web research into “flavors” of agile. I needed a system that was effective with the particular team dynamic of an early stage software startup, where everyone:

is highly motivated
is high performing
is not rigid role oriented

This means process is about organization and mutual understanding, rather than command and control.

After watching hours of YouTube talks on software process, and reading too many “experts”, gurus, organizations and systems’ websites I thought, “I’ll just create my own parody system”. I decided to make a website that masqueraded as a non-profit advancing my process management philosophy, but it would only be a façade. An few slogans and clichés, some links to media about this I like, and an Amazon affiliate link (mostly for the irony of a non-profit with ads). Although I had learned a lot, many of these systems seemed largely hollow, like schemes or cults, not much more than could be summed up in a paragraph of text and a few slogans. I also used the site to play with ideas of camp software design and new technologies in css.

So what is Jiko Kanri, really?

A cultural program for high functioning teams of well motivated professionals, and a system for organizing their work. A set of principles for the system as a whole, and for the two roles (manager and worker) in that system. It’s basically a Kanban style queue model with a lot of Toyota quality focus ideas and some other bits of my personal agendas thrown in. I believed (and still do) that it is possible to organize and lead a team to do their best work, without being rigid and controlling. Jiko Kanri lays this out and forms a short, shallow manifesto of how I’d ideally work. And indeed, I have since been lucky enough to work in places where I’ve been allowed to put many of these ideas into action, to good effect, IMHO. I hope you laugh at it, but laugh because it’s true.

Check out the root page of this website (the one you’re on :P)

For much more, pease enjoy this slide deck, which gets into detail about what I was up to when I created the web site.

The Limiting Factor

In high school chemistry, my excellent instructor, Mr. Gleich, drilled into us the concept of the limiting factor. It was so counter intuitive. Why wouldn’t speeding up any part of the reaction not speed up the overall reaction? It made no sense to me and many others, but he drilled it in. He used analogies, exercises and demonstrations… eventually, even though it’s counter-intuitve, it was clear: only the limiting factor matters.

As a newbie PM, I instantly recognized the same math applied in many situations I faced. I had a product or milestone, a chain of reactions turning raw materials into a final result, over time. I wanted to know how long the reaction would take, and where to apply the catalyst. And I still think this is the key to optimizing any process. Reducing pain, playing politics, and playing favorites has their place in deciding where to put your energy, but the only thing that will really make a process faster is ruthless focus on the limiting factor, enabled by a clear understanding of the rates at each step. You need to understand what the slowest, least efficient step is, but also keep an eye that optimizations to that step are not offset elsewhere in the process. Although a full model is helpful, action anywhere outside the limiting factor is not. Know the whole system, but act on one factor at a time.

To give a concrete example, say you have an enterprise product that has a per-client implementation process. Say you want to increase the number of customers you can onboard per month. If your can make the install process faster and the IT training smoother, but the real blocker is legal sign-offs on the contracts, your revenue will not really budge. If legal can only approve 4 deals a month, the number of trainings you can do is irrelevant to your goal. Of coarse, after you get legal to pick up the pace, you might find those trainings are limiting you after all, but that is what iteration is for.

That’s a simplistic example, but this applies to things you might not normally think of as “processes”, but can be modeled and attacked this way. For example, revenue is actually the residue of a reaction. Your product/marketing/sales meeting the market atmosphere. If there is a slow reaction, a low revenue per unit of time is the result. If revenue is slow, or inert, limiting factor analysis can identify what part of your hoped for, theoretical, market reaction is not happening. Marketing message not landing? Missing a key feature? Pricing wrong? Lay out your factors and their rates. Then act ruthlessly to improve the limiting one.

First of all, I love it; second of all, no.

One of the hardest parts of being a PM, in my experience, is embracing the needful thing of saying no… all the time.

It’s a sad contradiction that when you employ and empower creative people, you will then often have to stifle the same impulses they also thrive on. This means: the better the team, the more often you may have to tell people who are smarter or better at their jobs than you, “no”.

One aspect of managing this tension is knowing when to when to shut something down or let it play out, especially an early idea or loose talk. There is no formula for this. You have to know your team and the person who’s idea it is. If you constrain all thinking you get mindless pap, and work is a tiresome chore. But ideas can be dangerous. When an idea contradicts or undermines a core strategy or goal, it can be worth pointing that out early. If it’s more ambiguous or tangential, it matters less. Just be aware of who takes ideas too far, or can become obsessed with their own idea at the expense of the team or it’s goals. And, accept that creativity and smart people are risks to rigid plans.

To me, the hardest interpersonal aspect of managing with space for creativity is saying no without crushing people’s dreams. Especially if a shy or introverted team member is making an effort to express an idea. Be direct, don’t lead them on if the idea won’t be pursued. But also be encouraging, use a compliment sandwich, and let them know the reasons, if you can. Giving credit when someone does bring something to the table that ends up having impact, also is key. It’s ethically good, but it’s also a way to encourage similar efforts in their peers.

You might not be able to stand up to people, or to be able to tell the well meaning, shy, engineer his prototype he spent his weekends building won’t be turned into a product. Then you probably need a different career. Being a PM means saying no. If you’re not saying no (nicely), all the time, in all directions (up, down and to peers) you won’t last long.

Of course, don’t always say no! Don’t be a closed minded stubborn ass. Just be comfortable, or at least capable, when you do need to say no. You can also reduce the amount you have to say no by reducing distractions and by having strong buy-in from the team on strategy and goals. The more you can positively constrain their cognitive labor, the less you’ll have to do this. In particular, I have come to dislike open brainstorms. I believe they rarely result in anything useful, and there are many more effective processes for group ideation and creative thinking. They are political minefields in dysfunctional orgs, as well. Similarly, I am a big fan of concepts like hack-a-thons and ideas like 10% time, which encourage safe spaces for creativity, rich in cross-pollination and skill sharing. BUT, I’ve seen them go very wrong when there becomes an expectation that side projects, or hack-a-thon projects, will be incorporated into products. These should be temporary autonomous zones, not feeders for product development. If some new product emerges, that’s only a bonus.

Making software well, and enjoying doing it with talented teammates, means breaking their hearts sometimes. But you can learn how to minimize the chances, and the damage, if you get to know your team, and give them a clear vision.

Walkthroughs

I stole this idea, cause it was so good…

At Smule I worked alongside Kevin Sung, Kevin is a stellar PM and one of the sharpest people I’ve ever met. He had worked at Zynga, and learned the concept of the walkthrough there, which he spread to the other PMs at Smule. I immediately saw it’s immense value, especially before shipping major changes or new features.

Here, I’ll explain my take on the context, process, and benefits of a team product walkthrough, specifically for mobile devices, but really applicable to any complex software.

What you need

There are a few things your team and product will need to make the most of a walkthrough:

A set of user stories in an outline, or workflows for the features or product to be analyzed. If you have data which tells you common user flows and funnels, consider using those to write and structure your outline.
A pre-release build.
A collaborative note-taking document (at the Wikimedia Foundation we use something called Etherpad), but google docs and many other things will do.
The ability to steam a device screen (and ideally record) in a way the whole team can see.
A healthy team dynamic, and a team that can deliver and accept critique professionally.

The basic process

Gather the full development team for a product or feature in a room (physical or online). Appoint one person as “the finger”. This person will hold the device, and act as the finger of the platonic user or persona. This can be any person on the team. The device should be streamed (if the team is remote) or mirrored (for a room) and also ideally recorded for later review. Additionally a note monitor should be appointed. This person will write the PM and finger’s notes (as needed), and ask the PM to stop narrating if note taking is lagging behind the walkthrough pace.

The PM should begin to narrate the user’s basic motivations and desires, walking through the user story/ies to be analyzed. The finger is then responsible for actually finding and taking the desired action.

As this is happening the rest of the team are responsible for watching the stream and looking for issues. Notes and issues should not be discussed out loud (only the PM, note monitor and the finger should be speaking, by and large), but rather noted in the shared document. On the other hand ALL written comments and notes should be encouraged, be they bugs, useability notes, visual issues, brand standards, anything. Each function (UX, frontend engineering, QA, marketing, etc) should especially focus on their area, and attempt to look with fresh “user” eyes at their team’s work for the first time again.

At the end of this process, each team member should summarize for the team, their thoughts on the state of the app as they just saw it. Is it ready for release? Did they see any potential blockers? How do they feel about their work?

After this the PM, potentially in combination with team leads (depending on team size and product complexity), should look at each note in the doc and triage it. I usually keep it simple and do four buckets: blocker, follow-up, punt, ignore.

Blocker: the product cannot be released until this is fixed or remedied. I strongly recommend you file these immediately into your task management flow, to show the they are the most urgent, and came directly from the team’s efforts at the walkthrough.
Follow-up: the comment, note or issue seems relevant, but is too vague to be actionable. I usually turn these into personal to-dos, send a follow-up email, or add them to future standing meeting agendas (planning, standup, 1:1, etc).
Punt: the issue is valid but not a blocker or requiring immediate action. File and forget.
Ignore: the note is not valid, actionable, etc.

Key benefits and points

Besides the direct benefit of the issues found and improvements that result, this process has a number of other benefits for the product and the team:

User oriented: The whole process reinforces the primacy of a user and their story, increasing user empathy, and encouraging the team to think of their work as a whole experience.
Quality reinforcing: quality is everyone’s job, and everyone has their own taste. This process focuses everyone on the quality of what they are about to put out, but allows everyone to examine and express their opinion in their own area. It also provides a way for introverts and people who are better in writing to give feedback about the product.
You do it together: The whole team that delivers the product should participate. The line engineers, the ops guys, customer service, the marketing folks, anyone that shapes or needs to know this product or feature should participate. This encourages a sense of collective ownership and the summary reviews can be excellent ways for functions that may not normally meet to hear directly from each other.
Reality-based: like writing a term paper, it’s never a good idea to review your own work. Looking at each other’s work brings a dose of reality to the editing and iterating process. False impressions and misunderstandings clear up quickly in the light of a shared experience.
Follow-through: I cannot stress how important it is follow up on all legitimate comments and notes, especially the first few times through the process. If the team thinks they’re listening to you narrate the world’s boringest livestream, they will disengage and the time will be wasted. Consider their feedback seriously and take action where needed.
As Jeff Smith, CEO of Smule once (justifiably) told at a PM: “I don’t care what the numbers say. USE THE FUCKING PRODUCT”. This process forces everyone to see what it’s like to use the fucking product. That can only be good.

Debt

One of the perrenial topics at any software org I’ve been in, big, medium, and small, is “tech debt”. How much we have, how much we’re generating, why it’s the root of all evil, how it’s a bullshit engineer excuse. It’s a very popular metaphor, if often poorly considered.

So, let’s look closer at the metaphor, itself. The idea is that there is some level of quality, elegance or completeness that software should be at. However, it is in use at a lower level of quality, elegance or completeness. The work (usually measured in man hours, abstract points or development cycles) to move from the current, to the desired level, is the “tech debt”. You can pay it down, or keep racking it up. You can estimate how much you have. It will naturally grow over time, unless payments are made, akin to compound interest. Oddly, it’s also a kind of “friction”, which “slows” development, causes bugs and makes work less enjoyable. But, let’s set that aside for a moment, and talk about the implications of the debt metaphor.

One implication is that PMs, as the owner of the product with the debt, need to understand how to be comfortable with their debt, and how to manage it properly.

In the late capitalist economy it is not desirable to have no debt. Governments have major debts and will never pay them down (only forward). Citizens are heavily incentivized to get mortgages. Students need loans to make more money in the future. Eight in ten Americans are in debt, and despite what moralists say, that’s not a sign of personal flaws, but a natural result of a system where debt is advantageous. I would argue this all applies to software and technology as well. Being debt free means you passed up an opportunity.

Why? Because debt is moving growth forward in time in exchange for risk. If you can afford zero risk, then yeah, never have tech debt. Building nuclear submarine hardware drivers? Please have no tech debt. But most of us can afford some, managed, risk, and we can often exchange it for growth.

This applies to software very directly. Ship with a few features incomplete? You add risk of bugs, or that a missing feature would have been key to market acceptance. Running on an old, poorly maintained server backend? Risk of mass failure, data breaches, or dev ops revolts. But the flip side of cutting scope short is shipping to meet a sales opportunity. The good side of the old backend stack is that it works, costs nothing to maintain and is a well known quantity.

This is how to “manage” your debt load. Just as you try to fairly consider stakeholders input to come to the best solution, you can, for your team’s goals, step back and look at the benefits and costs of your debt. How bad are your risks? How great is the potential growth moved forward?

So if debt is useful, as long as it’s managed and risk is okay, why do teams, especially technical and design teams often view debt as only a great negative?

I would posit that it’s because of what engineers, and others, mean by debt. They deal with it every day, while for the PM and management it is more abstract, with benefits. But there is a pain to this very productive jargon, that they deal with in their lives. The reality is, they don’t like or understand their own previous, or their predecessors, work. Or they weren’t given time to do something the way they wanted, or as completely as they want. Or they need to refactor based on added features, or functions, or new models, or new best practices. They want something that was done changed, or they want to change something that was left undone. Sometimes they are right. If business imperatives, or you, are overloading them, debt will accrue. Risk will mount. And it will slow things down, and suck for them, and eventually your users. But how much debt to carry, and how risky it is, is for you to manage.

Unknown Unknowns

I fear the day that the MBAs and people that would have become “financial analysts” in the late millennium fully take over the culture of software product management. These are fine people, but they are abstract risk managers and value optimizers. They could be structuring financial instruments, selling jars of pasta sauce, or running software systems with almost identical approaches.

That said, my favorite framework from the finance industry that serves me every day as a PM are the concepts related to risk. Debt, insurance, investment and even team management are often about the accurate evaluation and management of risk.

The future is unknowable and we’re always dealing in probabilities and manipulating the likeliness of outcomes, not guaranteeing them. How do you handle this as the person most responsible for delivering success?

For any major undertaking, it’s important to think through and spend time on likely threats to the project’s success. But that only helps with the known unknowns, what about the unknown unknowns (to quote the wisdom of war criminal Donald Rumsfeld)?

Even when you don’t know the exact cause, it is still possible to manage vague, generic risk. Unknown threats generally come from a limited set of source types. The most common disruptions, in my experience, are the hidden stakeholder and the implicit requirement, both usually discovered late in the development process.

The hidden stakeholder means just that: it becomes clear that there is a function or person who might kill, block, or otherwise limit your success. The implicit requirement, similarly, is a story, feature or capability that limits or threatens your success, which you failed to identify during research and planning.

Think about what you would do to prepare. You’re gonna get hit by something: keep your head up and at least see it coming. Should one of these manifest, triage dispassionately: is it in your control? is it really a blocker or problem? Some things, like personnel losses and context changes should be accepted and accommodated. Some, like exec meddling, team stalemates or nice-to-haves becoming blockers, can be worth fighting to overcome. Some things, like technical risk, dance in the grey area between the two.

Of course, the real solution I always recommend agile development processes, and indeed agile thinking in general. The answer to not knowing the future is just to embrace that things will change, you will learn more and change is as much about opportunity as risk.

Camp Software

Wikipedia explains that camp is:

“an aesthetic style and sensibility that regards something as appealing because of its bad taste and ironic value. Camp aesthetics disrupt many of modernism‘s notions of what art is and what can be classified as high art by inverting aesthetic attributes such as beauty, value, and taste through an invitation of a different kind of apprehension and consumption… Camp aesthetics delights in impertinence. Camp opposes satisfaction and seeks to challenge.”

Camp is often applied to visual, performing and conceptual art, along with lots of movies and TV, restaurants and experiences. RuPaul is campy, John Waters is campy, Benihana is campy, an art car is campy. But can it apply to software? Can you make meaningful or even “popular” software that “opposes satisfaction”? This website’s own home page was my attempt to work in an aesthetic I thought was so ugly it might actually be cool and to oppose satisfaction by providing only the shallowest of explanations of what Jiko Kanri is.

But there has to be much more out there. Apps with ironic look and feel? Does that count? Or tools made intentionally hard to discourage their use. We’ve all seen web sites we could easily describe as “over the top”. Every Chinese social app I look at seems to be inverting the normal values of software design to stuff the screen with every function and text it can find a few pixels of space for. Is that camp? Is Snapchats “old” unfriendly, gesture heavy UI and attempt to be impertinent and to challenge users to learn new things through word of mouth, excluding the conservative of habit and the un-networked user. Is that camp?

One effect of the usefulness of software, and its categorization as a medium for tools and games, is that media theory, which is rich and insightful about movies, TV, news, music, you name it, seems to treat software as outside its view. Website and trends might be analyzed and deconstructed. But non-game software is not subject to the same level of critical and analytical thinking. I enjoy watching YouTube videos by movie and cultural critics. These lengthy reviews, analyses and essays are interesting, insightful and show how media like TV and movies work. How much of that is possible for software? Most software videos are tutorials or shallow reviews. I understand these apps are tools.

But I also know: Software is a medium.

I want a more popular, useful, fun, interesting media study of it. And I want to see weirdos like me celebrating software so ludicrous its tragic, or so tragic its ludicrous.

Data Games

One of my least favorite kind of PM compatriots are those who insist that they are purely data driven. Like all zealots, they’re often tiresome bores, and while there is a lot of truth in what they advocate, their smugness and certainty is off-putting. But, of course, numeric measurement is useful! So here’s a few downsides of shallow quantitative methods, as a dose of skepticism for all you quant advocates.

I think the greatest downfall of data driven approaches is picking the wrong number to build a goal around. If you work with smart people, even the best intended will game a simple numerical target, when selected without care and consultation. In one of my favorite stories about this, a company decided to set sales quotas by weight of items shipped from the warehouse. After months of record setting sales, accounting realized the weights shipped didn’t match the actual revenue the invoices reflected. The sales people had paid off the warehouse guys to add bricks to the shipments.

Another pitfall is not actually understanding whether the KPI you are tracking really means what you think it does. If a number is a “proxy” or “simplification” of some more complex behavior, beware! Always understand what the numbers really represent, not what they have come to represent to the team, especially when working with a mature product. What events trigger them? Don’t assume something labeled “conversion” is actually when revenue is generated. Look past the numbers to the underlying activity.

The next step is to move beyond description to analysis. Always be looking for the story. Why a number is, not just what it is. What does it mean? Being data driven doesn’t mean putting graphs in your decks and having dashboards. It means using quantitate data to make decisions, and understand how people use your product. Explore your data. Don’t just refute or prove theories with it, discover hidden failure points and identify new opportunities. If you’re lucky enough to have a good analytics system, get immersed.

And woe, beware the data driven emergency! I have seen many many times an urgent alarm is raised based on a single chart or number. Something is down, something is up, this looks way off. I would estimate that 90% of these end in one of two ways: a bug in the data, or a misunderstanding/change of definition. Analytics are tricky systems, and events and calls can easily move or change implementations without everyone knowing. Before you freak out, eliminate these options.

Numerical data is not an inherently superior or more honest. It’s as easy to lie with numbers as stories. It’s as easy to have bad analysis as bad taste. Always be scientific with data when you need to know the truth: taking measurement without prejudice and being clear eyed in your analysis. But be lawyerly with data when you use it with others. Pick and choose the evidence that best supports you, not lying, but treating the data as secondary to the narrative. In the end, I believe, data is there to build and support the narrative, not t’other way round.

Software I’ve Loved

Someday we’ll really understand as a society, and maybe people younger than me already do, the central role software and it’s interfaces play in our culture now. UIs are now era defining, and can be mass critiqued as any product of a collective creative craft, as we do with movies, television, news and other media. Somewhere there are kids that love software as young Speilberg and Lucas loved movies. Somewhere there’s a little girl who dreams of software, just as there are girls dreaming of becoming the next Shonda Rhimes. I hope we give these kids the spaces and ladders that film, publishing and so many other media offer their most adamant fans. We need to show them there is more to software than programming, just as their is more to movies than acting, and make being a “software nerd” something more than learning to code, just as being a movie nerds is more than learning to operate a camera.

One potential way to do this is to encourage a “culture of software”, where newbies can hear not only about process and technology, but where there is a robust critical discussion of software itself, its language, trends and tropes.

And maybe this exists, but certainly not as much as the cultures that surround and support older media.

As my meager contribution, this is one of two essays which focus on 3 classic pieces of software. In this one, I have 3 I’ve loved, and why I loved them:

WriteNow – Back when GUIs were coming to mass market maturity with Windows 95 and Mac OS 6, word processing was still new enough to be cool. Our little Mac SE’s beautiful fonts and ability to do things like multi-column documents were the forefront of what computes could do for home computer users like my family. It was the age of the “desktop publishing revolution”. An early, simple, disruption that would, in many ways, presage the broad democratization of media creation that would follow. At this time, there were multiple word processors, and Word was just beginning to bloat. But above them all, from my POV, for years, sat a little Mac word processing program called WriteNow. It fit on a single 3.5 floppy, loaded fast, was responsive, and was easy to understand and use, with a nice clean UI. Best of all it wasnt’ bloatware. It was full featured (it did footnotes!) but wasn’t hyper customizable and it didn’t have paper clip to help you. And that was the triumph. It knew what the core of a word processor was, and it did it well. Sadly, it didn’t survive the era, and eventually I succumbed to using the beast that is Word (for a while). But its spirit lives on in MacOS’s TextEdit. TextEdit is fine, but is slightly too bare bones (though it too has grown some extraneous features over 15 years). WriteNow hit the sweet spot in its category at a time when this category was the killer app for the home PC. I don’t think it was a mass cultural phenomenon like Word, but for this user, it was software worth loving.
HyperCard – HyperCard is an historically important piece of software, and the first really broadly available system for hypermedia. It expanded who could build a GUI, was the vehicle for the first wiki, influenced the World Wide Web and gave us the ancestor of Javascript. It was my first introduction to event driven programming and first chance to play with GUI design. It was so powerful, yet easy to understand. It was a stack of metaphorical cards you could program to do anything. I made animations, games, simulated spaceships, anything I could think of that fit into the 512×342 black and white pixels of our Mac SE. Like the best creative sandboxes, it was constrained but almost infinitely expressive. If you’re not familiar with HyperCard and its role in software history, I recommend reading about it, or even giving it a go on an emulator. If you’re young, it may feel like getting into an antique car: you can see all the bits were there that make up much of todays software, but just a bit lower res, much less safe, not on the internet, and way slower.
IntelliJ – When I started building Android apps, in my Developer Evangelist role at Greystripe, the only viable way to do that was to download Eclipse. Eclipse is a great gift to the world, a free open development environment. But it is not good software. Confusing, bloated and overly customizable, it was my least favorite part of building Android apps. At my next startup, the CTO immediately asked me why I wasn’t using IntelliJ. It was a free, beautified a tool, that makes doing hard things much easier and was light years better than Eclipse. I tried it and was hooked. I soon noticed this tool was everywhere. Our developer partners were making the change quickly, and en-masse. It was fast market disruption by a superior product in action. I had to rewrite our SDK instructions a couple months later, due to the volume of devs asking for IntelliJ based instruction. The JetBrains people continued to make great editors and software tools. Though I don’t do much Android programming these days, I was not surprised to hear Google’s Android Studio was being developed as an adaptation of IntelliJ.

So what do these have in common: performance, knowing their purpose and serving it well, expressiveness, elegance. They all enable me, make me more creative, and make making things easier and less annoying. Great software is an admirable cultural object, but it is also a tool, and these 3 tools have not only been impressive in their own moment and category, but they also served as the spark for untold amounts of second order creation.

Software I’ve Hated

Although I prefer my list of software I’ve loved, like most media, most software is bad or mediocre. And some of it is painful, annoying or even deadly. Unlike movies, software robs and blackmails. That’s hate-worthy. But, for me, the software I’ve hated most is software I’ve used a lot, but that share(d) some key characteristics. Not just annoying to use, but really obviously flawed in a fundamental way, but ultimately popular anyway. Like a shitty movie that makes millions, these are product that may touch many peoples lives, and may be “successful” by most metrics, but which fundamentally fail as software. That makes me hate them.

Eclipse – The invert of IntelliJ. The first couple times I tried to use Eclipse in grad school, I literally gave up on the intro screen. It had four options, none of which were straightforward actions like create a new code file. I clicked one. It was some kind of package manager, but for plugins? I was on a Mac, it looked like Windows (I guess it was/is Swing?). My fan whirred on. I hadn’t written a line of code and my top of the line laptop was having to give it’s all. A few years later, when you had to use Eclipse for Android development, it had improved. I made it past the launch screen. But it remained ugly, slow, inconveniently and excessively customizable, resource heavy, cluttered with too many features I didn’t need and lacking some basics I expected. It’s integration with the Android toolchain was brittle at best and more often wall-punchingly inane. I kind of liked building Android apps, but I very much hated Eclipse.
iTunes (some versions) – A clichéd choice but a necessary one. I’ve used iTunes since its primary purpose was to rip and burn cds, and manage your music library. It also had an equalizer that was fun to fiddle with, and a visualizer that was a beautiful demonstration of the Mac’s graphics power. Then came the iPod, and the Store, and sharing, and Podcasts, and the iPhone, and videos and tv, and iCloud, and iPad, and TV again, and Apple Music and Ping and and OMFG this interface makes no sense. Each view is different… what is wrong with a sortable table? It’s fluctuated in usability. The version in Sierra is useable, if confused and inconsistent. But boy, have their been updates where I thought, “the designer of this literally hates people who want to use this workflow. They did this to vex me.” And, yet, it’s running even as I type.
Explorer – For a period Explorer was the best browser available for OS X and I used it voluntarily. It was resource heavy, but fast and its rendering was spiffy looking. At other points in my life, I’ve used Explorer, but always found it to be ugly, slow or just not worth the download. But there were also points where Explorer was the worst and I worked in companies that mandated its use. I actually liked Windows NT okay. But I remember cursing the name of Bill Gates sitting in a shipping office in Seattle, as a temp, trying to load a large page of information into my little desktop and not enjoying my experience. Also as someone who’s done web work, fuck Explorer for their non-compliant weird old browsers still causing problems for web devs and users worldwide.

What do these three POSes have in common? Complexity, slowness, monopoly. They are tools that do too many things (or try to), do them slowly or unstably, but that I had to use. Even though Eclipse is a FOSS, non-profit, at that time, on Android I was not free. There was no real market or competitor, and that led to shitty bloatware.