Create Jira Issues From The Command Line

You can use the command line to create Jira tickets. In the below one-liner, we’re going to bring in some standard json and create a ticket. We’ll use curl and use -u to define a username and password, then -X to define a POST and –data to define the contents of the post, wrapped in the single quotes below. Then -H defines the content type as json and a URL to your Jira rest endpoint, “Issues” in the below code:

curl -D- -u krypted:MySuperSecretPassword -X POST --data '{"fields":{"project":{"key": “DOG”},”summary": “Make my feature better.”,”description": “Going to make everything better ever ever ever by doing things and by things I mean allll the things“,”customfield_001”:”Testing testing”,”issuetype": {"name": “Story”}{“time tracking”:{originalEstimate”: “2d 4h”}}}’ -H "Content-Type: application/json"

You can swap out the json here with input to a script, or a file. That json can look prettier than it looks in the above single line:

    "key": “DOG”
   ”summary": “Make my feature better.”,
   ”description": “Going to make everything better ever ever ever by doing things and by things I mean allll the things“,
   ”customfield_001”:”Testing testing”,
   ”issuetype": {
    "name": “Story”
    “time tracking”:{
    originalEstimate”: “2d 4h”

As you can see, we’re creating an issue in the DOG project (which could also say CAT or whatever was generated when you created the project you’re putting this issue into). We’re then adding a “summary” and “description” as I don’t think you can really create one without that information. Then we’re adding information for a custom field our organization created and finally an estimate for how long the task should take, with those being very much optional.

So any other fields you have available can also be created as well, just add them to the correct part of the json with the correct label and inputs to accept.

Jamf Freshdesk Plugin

Ever wanted to be able to view devices from your Jamf server from within your Freshdesk environment? Well, I just posted a new integration on the Jamf Marketplace just for Freshdesk.

This plugin will display a search bar on the right side of the screen. Enter a serial number to find your devices. If a match is found, you’ll see information on the device (note: this is up on GitHub so you can change what fields you see).

If you don’t find anything that matches a given pattern, you’ll get an error.

Some Reasons Not To Pay Down Tech Debt

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.

My Huffington Post Article: From Dungeon Master to SCRUM Master

My latest post on Huffington Post is “From Dungeon Master to Scrum Master: 15 Software Development Lessons from Dungeons and Dragons” and is a bit of a revamp of my D&D article from here, but geared towards SCRUM mastering and managing Software Development teams. You may find it fun and kitschy or you may find it dumb. I’m kinda’ ok with both (I’m learning that I can’t make all the people happy all the time). A sampling of that article:
I started playing Dungeons and Dragons in about the 5th or 6th grade. I didn’t get good at it for a while, but once I did, I didn’t play much longer (insert reference to “The Best Days of My Life” here.) Dungeons and Dragons taught me a few lessons that I didn’t realize would turn out to be great life lessons, until I was much older. This childhood game taught me life lessons that I would eventually apply to the business world – more specifically, the world of software development – and I know I’m not alone. In fact, there is a distinct possibility that many a developer got their start scoping out character sheets, and many a Scrum Master began as a Dungeon Master.
Here are a few of the lessons I took away from those carefree days. And yes, this image is from a box set sitting on my table at home. Don’t judge.
1. Build a great campaign, and if the game is good, expect your players to break it. 
In software, we design workflows. Then, users take routes we never thought possible. You build a product, sell the product and potentially service the product long-term. Maybe it sells, maybe it doesn’t – but if you’re not ready for the sales to happen, you won’t sell that much. How much work do you put into building a campaign, or game, in Dungeons and Dragons, if the characters are just going to go right off your script? How much effort do you put into building a business if the customers are just going to buy something from you that is completely different than what you thought you were going to sell? These are the same questions, and there’s no right answer to either (although there are many wrong answers). Understand that when momentum strikes, if you don’t have a good campaign built that is flexible, you won’t maintain that momentum. And if you haven’t thought of all the various routes a user can take around your software, you’re going to have a bunch of lost paladins mucking around in swamps with no monsters!
To read more, click here. Screen Shot 2016-04-10 at 5.24.24 PM

Article on Content Strategy on Huffington Post

I’ve been thinking a lot about content strategy and the why and when of how articles are posted. I’ll keep writing whatever I want, whenever, often times based on what I happen to be working on at that moment. In other words, I actually have no content strategy for krypted, and I don’t feel the need to implement one. But at least I explored it, thought about it, and got a few notes down for friends who do want one, or are thinking about it. That article went up on Huffington Post yesterday at A snippet of the article:
Search engine optimization (SEO) involves strategies and techniques that, when used properly, increases the amount of people that come to your website via search engines, like Google, Yahoo, and Microsoft Bing. Getting enough content, and more importantly the right content, on your site is your content strategy. As a business owner you always need to try new, interesting, and interactive ways to promote your company. And one of the best things you can do is to create a good content strategy for your organization’s website.
A business owner, or marketing employee in a small business is likely to wear a lot of hats. In large companies, there are often teams of people creating, editing, releasing, and strategizing what content to create on a website. How does a smaller organization compete for a similar audience? A good content strategy at a small business can help keep you focused and provide a unique experience to your readers. You can get material out faster than if articles have to pass through multiple layers of approval before going public. Timely pieces can mean getting to audiences before the competition can catch up. And having a personable and authentic voice can keep readers coming back to your site.
Not only does a good content strategy allow you to take your business to the next level, but it also offers a wide range of other benefits, as you can see below!
Screen Shot 2016-03-30 at 8.47.37 AM Click here to read more… The one point I didn’t think to make was once you have a good content strategy in place, it becomes much easier to outsource the creation of content. You can bring in professional content creators (writers). And then you can hopefully just edit their work. I’ve never had the greatest of luck with that, so I just keep writing stuffs. But I know a lot of people who have, and a lot of people that do this work, and do it really… really… well!

Interview with Chuck Joiner of MacVoices re: Bushel

My third podcast in the last couple of months, this time with Chuck Joiner again, of MacVoices. And we talked a pretty good bit about Bushel and Mobile Device Management. Thanks to Chuck formatting this whole thing pretty awesome and helping bring my explanations to a point where they actually make sense!

How Product Managers Feel When New Features Are Loved By All

You get requests for features. Lots of requests. What do you pick? Why? Sure, vote up, vote down, statistics, choosing people you respect, looking at potential new customers, and tons of other attributes go into this, but at the end of the day, there’s a judgement call. And some people hate what you pick. But sometimes, everyone is into it. Yup.