Tiny Deathstars of Foulness

12 years ago today I posted my first article on this site. My publisher at the time thought I should have a website, so I made one. And after over 3,500 posts, I’ve watched the industry change so much!

I have always written about what I do. Because of that, the past couple of years have seen a slight shift from Apple device management (I mean, I still write about that when I feel like it) to more technical management and leadership articles. These days I also have contributions scattered all over the place, from publishing code on GitHub, to writing about technology and leadership for Huffington Post, to Entrepreneurism for, to writing about scrum for devops magazines, to books on mostly servers and security for O’Reilly/Apress/TakeControl, and finally to activism (and hacktivism I suppose).

I’ve taken some criticism for veering away from my core. And I’m OK with that. But I always come back here and post links to the other writings and podcasts and public speaking engagements even if they do go in a slightly different direction. And I still do an annual guide on OS X Server. This year I didn’t write a full-on book, as there was only one new checkbox, but I will when there’s more to write about – and I did update and expand the annual free guide. I also still write on mass management of Apple devices and whatever else I feel like writing about, but I don’t just do that any more, so I write about other things as well.

Mostly though, I am honored so many people come to the site. I am always so grateful when people mention the site, say thank you in passing, ask me if I’m krypted in the bathroom (that happens), punch me for screwing up their server, or post comments asking follow-ups. It helps to know I’m not just writing for web crawlers and bots (although my preference is definitely to not get punched).

So thank you for sticking with me however long you’ve been coming here! And please, feel free to recommend articles or if you’d like to do some guest posts (or become a long-term contributor) let me know and I’ll get you an account!

December 30th, 2016

Posted In: Articles and Books

Tags: , , ,

Chuck Joiner was kind enough to have me on MacVoices again, this time an episode focused on Holiday Gift Guides. I’d tried to stay sub-$50 but then Chuck totally stole some of my selections. We laughed. We cried. Hope you enjoy!

December 7th, 2016

Posted In: Articles and Books, Home Automation, Interviewing, public speaking, Wearable Technology

You work for weeks, months, or years to build a business that is killing it. Then you get a huge new customer. You feel like you’ve been put on the map. But then the reality sets in. Maybe you won the business because you’re innovative, less expensive, faster, etc. But now you start getting completely destroyed by the overhead of making those sweet, sweet dollars from that new customer. Wouldn’t it have been great to have known about a few things to ask about? My response includes a few tips on how to work with them, that just might save you some serious margin!. Check it out at


November 18th, 2016

Posted In: Articles and Books

Tags: , , , ,

My first piece on is up at and deals with Social Networks that you might not consider social networks. I should probably do a follow-up on fair play on them… Either way, hope you enjoy.


November 2nd, 2016

Posted In: Articles and Books, Business

Tags: , ,

Here’s my deck from MacSysAdmin, if you’re interested in such things.


October 5th, 2016

Posted In: Articles and Books, public speaking

Tags: , , ,

My latest post is up over on Huffington Post. It starts a little like this:

You work hard, you work harder, and then you get a montage. The montage starts when you get hit in the face with a pizza by the other engineers on your team. Then you get a little better as Bon Jovi or Tina Turner belt out a power ballad just for you. Then things start to click. You catch the bugs before you compile, you close all the tickets in your queue, and finally you get carried out of the office door on the shoulders of your coworkers, given the key to the city, and promoted to Grand Puba. It’s awesome.



September 22nd, 2016

Posted In: Articles and Books

September 10th, 2016

Posted In: Articles and Books, iPhone, Mac OS X, Mac OS X Server, Mac Security, MacAdmins Podcast

It’s funny how you write an article exploring why technology initiatives fail and it ends up becoming another list article. But at least the spirit of the thing survived editorial. And a special thanks to the editors of this piece for making it more accessible! To read more on my perspectives around why various technology initiatives fail, see

Screen Shot 2016-08-31 at 12.06.21 PM

August 31st, 2016

Posted In: Articles and Books

Tags: , ,

Every development organization has tech debt. Modern development projects have gotten so large and complex that there are now dozens of libraries, frameworks, and services implemented in a modern solution. Additionally, there are always new techniques, new modules, new frameworks, new skills, and new perspectives. Applications are now ecosystems, constantly evolving, and our perspectives about them must evolve as well.

Yes, a burn down chart looks better when you pay down the debt. Yes, security flaws can force you to pay down technical debt. Yes, most developers always want to fix all the things, including impending dead technology. Modern solutions have many stakeholders. The modern roadmap has to include benefits for existing customers, senior management, the people you send into the field, and net-new customers, coming in based on new features that need to get implemented.

You can’t implement new features that help to retain customers and acquire new customers if you are always paying down technical debt. Here are 10 good ways to tell if you need to re-evaluate plans to pay down some technical debt:

  • There’s a new version coming out. Let’s face it, there’s always a new version just around the corner. But a release can be imminent. Take into account the timeline of a new release and choose where to spend your precious development capital, being careful of frameworks, libraries, and services that have a new version about to come out.
  • A version is too new. A cooling off period is necessary with any new technology. Otherwise, you’re learning about all the bugs and limitations of a new solution in real-time. The larger a development organization, the longer it takes to develop the institutional assets required to perform a large-scale effort to implement new technology. And the greater the risk if you go the wrong direction. For example, if you are already updating production applications to Angular 2, are you sure that’s a good idea?
  • You have to retrain an entire team. Retooling an entire scrum team, or larger efforts require you to rethink how you approach various problems, and can require hundreds of hours of training for engineers. When you are looking at larger projects, consider how much time the new tools will save versus the cost to bring in experts to train your staff, as well as the hours required to actually do the work.
  • You can’t hire talent that know the new technology. This is a huge red flag. Maybe you can’t hire someone to help you out because the supply is tapped, maybe you’re trying to implement a framework that’s too new, maybe the library is too old, or maybe it just plain sucks. Either way, if you can’t find engineers willing or able to implement, rethink the whole situation.
  • The cost of doing the project is greater than the cost of other efforts if you do not do the project. Not paying down technical debt accrues interest. That interest can build up over time. But what if it doesn’t? What if the new project makes others more complicated, or doesn’t simplify others? Consider the impact to other initiatives, both positively and negatively when prioritizing your technical debt; especially smaller projects.
  • You have to replace other parts of the solution to make the new parts work. We’ve all been there. You have 4 libraries that don’t work with the new framework. If you start the implementation of new technology, you’ll want to check on each interconnected framework and library prior to beginning to do so, if only so you can properly estimate the time required.
  • Solutions come with new licensing requirements. As noted, most modern projects are ecosystems of dozens of open and closed source libraries (if not more). Many teams now keep a document, or entire database, of the types of licensing used for each of the building blocks that make up the stack of a given application. Each time you update to a new version, you’ll want to first validate that you aren’t entering into an entirely new set of licensing terms.
  • Initial tests go poorly. OK, so you don’t need to scrap a project just because projects where you attempt to scratch the surface go poorly. I like to start with some small wins, stick my toes in the water, and then re-evaluate timelines based on how the initial tests go. You want to get some nice momentum on the burn down chart before you head into deeper waters when doing larger development projects.
  • You can’t compartmentalize the new technology. Let’s say you’re implementing React Native into an application. You already have a user interface that users have been using for, in some cases, several years. Can you implement React on a screen-by-screen basis, or given the architecture of your existing app, will you have to do the whole thing at once? If you can’t compartmentalize the new technology, is it really right for you?
  • You are spending more to pay down technical debt than on new features. Mature products often get you into a place where you’re spending more to keep up with your existing code base than you spend to implement new features in your tools. When you get into this kind of scenario, you definitely need to stop accruing technical debt; however, you should re-evaluate whether a much larger rewrite would be more appropriate than fixing little things here and there.
  • Your goal can be accomplished in another way. Let’s say you have an API, and you never bothered to ship documentation on using the API. This is actually pretty common. There are tools like HATEOAS ( that can allow you to basically self-document the API within the API. Is it better to do that or publish a quick PDF on using the API? Either way, you need the PDF. Most of us would, if time allowed, prefer to go the HATEOAS route; however, again, we have to be judicious with our time.

Ultimately, we all have a limited pool of resources. And as our solutions grow, the amount of effort required to update parts of the code will grow as well.  A lot of these tips involve taking into account the resources required to update the building blocks of a larger application, or project or timing. There’s no doubt that the longer you incur the debt on each of your initiatives, the more interest each incurs. But sometimes, it’s important to keep a larger picture in mind.

With limited resources, there is no right answer when it comes to keeping your code modern. You don’t want to accrue too much technical debt. Otherwise code will become unwieldy and developers will run away from your organization when they realize just how much of a hurdle it will be to update your code. But you have to implement new technology in order to keep from keeping up with 30+ year old FORTRAN code in 2016. Next time product management and developers compete for prioritization, check these tips, and see if you’re going down the FORTRAN route, or keeping too modern; hopefully it’s somewhere in the middle.

August 11th, 2016

Posted In: Articles and Books, Product Management, Programming


We’ve all got a box sitting around somewhere, full of cables and devices that used to blink away at us until we snuffed the life out of it all by replacing it. Some of us have 10 of those, full of tangled cables that maybe went to that one camera that we lost in 2009. Many of us remember the exact price we paid for each device in those boxes, such as that $699.99 firewall. It can be challenging to replace that device with one that costs 10% of that price, even though it’s more than ample to meet our needs. And we have a hard time imagining that after only using the thing for 6 years that it’s now out-of-date. After all, don’t I still have that one sweater I bought during my freshman year of college? Won’t I need that laptop I replaced 3 years ago?

Chances are that you should burn that sweater and send the firewall and old laptop off for recycling. Of course, always make sure that you won’t be losing some data and have a backup of anything you’re getting rid of (that stored files), but chances are that some of that old stuff is completely incompatible with modern systems. Some things you should also consider throwing out:

  • That old tape drive that has the backups from your server from 10 years ago.
  • All those cables with pins in them. These days, HDMI, Lightning, USB, and Thunderbolt has completely replaced cables that have pins that get bent. They were great when the industry was young, but if you’re tossing things out, get rid of those old things…
  • Old monitors. Yes, that 15-inch LCD cost you $500. No, you don’t have any devices that use the kind of cable that connects it to a computer.
  • Old hubs, switches, cable modems, wireless access points, and firewalls. These days, most things are wireless. If you have a bunch of old devices that connected various Ethernet-based systems sitting around, toss ‘em. If you need to buy a new one, it will be super-cheap, and putting an old one on your network is likely to cause poor performance, network-wide. Old network appliances can also conflict with the addressing used on newer devices, and can cause outages.
  • Old printers and scanners. These days, you might go months without printing, and like old cars that haven’t been driven in forever, they might require a mechanic to get working. Printers are $50 at Target. Ink costs more these days. When a printer has a problem, give it a good clean, and if the problem persists, recycle!
  • Apps that charge you a recurring fee. Yup, these don’t fit in that plastic bin with the wires, but they cost you money. Likely every month. Everything from cloud services you tested to in app purchases that are billing monthly should be reviewed and cancelled if no longer needed.

Just toss all of it out. It will feel liberating to do so, and you’ll free up those plastic bins for other more useful stuff, like those VHS tapes of the Golden Girls!

August 10th, 2016

Posted In: Articles and Books

Tags: , ,

« Previous PageNext Page »