Software development explained with Cars

The only thing more difficult than building software for a client is explaining how software is built to a client.  So we sat down to explain this incredibly complicated concept the only way we knew how – with pictures, and with cars:

Special thanks to Dan H. for pointing this most excellent infographic to me.  The folks at Toggl have outdone themselves.  I live in Michigan and I find using Cars as a metaphor works to explain complicated stuff.  I plan to make a post from this for my office.




Thinking Fast and Estimating Wrong — JSFeeds

Software estimates are fundamentally flawed. I’ve always intuitively known this, but a year ago, I did a little experiment inside Zapier to prove it. Now when I say “prove,” I don’t mean full-on lab coats, large population, double-blind, scientific … more

I have added this book to my listen list on Audible as a result of reading this short post on the experiment to show how as humans we can’t estimate effort and time worth a damn.  The idea of story-points (Scrummy) like 1,2,3,5,8,13 eliminates the fear of estimating low and the problem with the “bid once bid high” mentality.  Each of the story points is “Around” a number of hours giving a little bit of flex when doing resource planning.

via Thinking Fast and Estimating Wrong — JSFeeds

The real origins of the Agile Manifesto,

In February 2001, 17 people met at the Snowbird ski resort in Utah. They were the leading exponents of Extreme Programming, Scrum, and Adaptive Software Development, and they were seeking a set of compatible values based on trust, respect, and collaboration.

They wanted to make software development easier. And they found it in the form of a manifesto. Their only concern was that the term describing the manifesto came from a ‘Brit’ and they weren’t sure how to pronounce it.

The Agile Manifesto was, however, born …

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation\
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

While they saw value in the items on the right, they valued the items on the left more.

The 4 bullet points above are what Agile is about not Scrum, standups, sprints, retrospectives, story points, and backlogs.  If someone says they do “Agile” and follow it with one of those words they are full of it.   I attempt to follow the manifesto anywhere I work but most of the customers still want process definitions, detailed specification documents, and SLA’s, ISA’s, DUA’s, DSA’s with a detailed Microsoft Project Plan.  Old habits are hard to break and distrust is still rampant.

All the things in the manifesto are important the most would be trust.  The focus should be on making things, things that people want to make their life easier, things that help us know how to build things and things we will teach others on how to build things.

Via: Redgate Blog

We can’t solve the problems by using the same kind of thinking when we created them – Task Management.


With the continued advancement in the tech world and development of top notch software, the need for a robust task management tool has never been this important. No wonder why businesses are switching from the old system to a new automated task management system that simplifies work place activities. And for companies who have invested…

When I bring the topic of task management to some companies I get back. “We have E-mail, Word, spreadsheets and a shared drive, we’re good.”  Yea… no your not.  This might work for a single project but not when you have 10, 20 or more projects at a time.

I preach the use of task management software dedicated to the process of watching over each project with the ability to zoom up to see the entire workload.  Use something like JIRA or Basecamp.  There are cost and some start-up learning required.   Make the investment in your survival, read this article as it is very insightful.

via Top Five Reasons Why You Can’t Win Without Task Management — DZone Agile Zone

Progressive Web Applications – What?

Progressive or not progressive… If you have been designing or developing web applications for a while, you would have probably came across the term Progressive Web application a tons of times, and will probably do so for the coming years. You probably wondered what exactly is the definition of… Link: Progressive Web apps recipes for […]

Progressive Web Applications, this is not a new term or idea.  But, it has had a few different buzz words attached to it over time.  This article is good at defining this, even it is from a Java focused site 😉  It also has some awesome infographics about the mobile share of the marketplace.

Less is more is my motto when talking about technology.  If you use too many words, especially buzz words, to describe a technology you have failed in helping people learn about it.

  • It a single web application
  • It is NOT a mobile application (Apple Store/ Google Play)
  • It works everywhere on anything
  • Thay are designed for mobile devices first
  • Loads fast, runs fast, reacts fast, it’s fast
  • Can work offline or with shitty internet connections
  • Can be “Installed” on home screen
  • Looks like an “App”, behaves like an “App” but, it’s a web application
  • It’s just a URL that can be shared
  • Developed using some newer frameworks and development practices

via Progressive Web apps recipes for GWT — Techie.Buzz

Learning over Delivery, the Experimentation culture, it’s OK to be wrong


Large organizations want to be like lean start-ups but they need to rethink how they hire, incentivize and manage their staff to become an agile organization. Organizations should reward teams for making low-risk decisions based on what they can learn quickly and build in the value of learning in addition to delivery. By Ben Linders

“Look what I did!”  is one of the favorite statements I like to hear from developers in the teams I work in.  Like a parent who hears this utterance from their child sometimes you are amazed and at other times you just say “That’s nice”.  You never discourage the kids from trying things out.  This includes those kids who just happen to be developers.

Many companies don’t embrace the “Need to Learn” in order to be relevant.  This results in me getting calls to help companies replace developers who have left with the explanation “I’m stagnating here, my skills are drying up”.

I didn’t know that “Failure” was a four-letter word.  A mistake you learned something from is not a failure.  A mistake you repeat and never learn the lesson is the failure.

This interview with Jeff Gothelf, author, coach, workshop leader and public speaker, is about Scaling Lean at Craft 2017.

via Scaling Lean Startup: Principles over Process — InfoQ

Moving a JIRA Cloud instance to a Server instance using AWS

JIRACloudLogo.pngWe have been using JIRA On-Demand or JIRA Cloud for a few years now.  It was an easy SaaS decision and helped us get started very quickly.  After a while, we realized that most of the cool add-ons for JIRA are only available to the JIRA Server instance.  Our web applications have an Issue-Track (Critical-Response) form  that users fill out to report a problem or ask for an enhancement.  Currently we take these forms and manually transfer them into JIRA.  The JIRA licenses are too expensive to give all our customers a JIRA user ID’s.  So we designed an integrated JIRA interface into our Issue Track page that talks direct to our JIRA-Cloud  Instance. No more copy-paste.  One of our government customers has a security rule that only allows API usage to servers with a single IP address.  Well, JIRA Cloud instances from Atlassian are actually hosted on Amazon Web Services which uses a pool of IP addresses for better performance which makes sense.  For us to get a single IP we will need to migrate our JIRA Cloud instance to a JIRA server instance.  We have decided to stay as close to the way Atlassian manages their cloud instances so we will be using AWS as well but, with a single IP address.  I will document this journey over time in this Blog, one for some reference documentation and two because I like to share.



Couchbase uses Swagger to tame the API Monster, so should you

Couchbase incorporated Swagger into our documentation a few months ago. “Swagger” refers to an ecosystem of tools and other resources for managing REST APIs. Core to Swagger is the Swagger specification. (The group behind Swagger donated the spec to … more

My business card states my title as “Technology Evangelist”. I learn technology, use it in solutions to the point where I can teach it to others then I preach it.  My audience is mostly people who probably think I’m a little crazy.  When it comes to REST and API’s the answer I recommend now is using Swagger and its toolset to design, manage and document your valuable API’s.  I scream every time I see Word/Excel/Email documents beings used to define API’s in large systems.   Using 20th-century tools to manage modern 21st-century processes like API’s doesn’t scale and helps contribute to some of the failures I have seen.

via Managing REST APIs with Swagger (video) — JSFeeds

Backlogger web app released to Github, it’s a Scrum thing.

2017-03-07 12.30.08.jpg

“Backlog” is one of those SCRUMmy terms used to identify features or functions that have been dreamed up or discussed for an application.   You collect these ideas into a list which is called the “Backlog”.  Then this list is reviewed (Sprint Review) and the ideas are refined (Groomed) and an estimate of effort (Story Points) is assigned to it.  Then folks get together and discuss which ones should be done in the next timeframe (Sprint).  To collect these ideas some companies use an issue tracking system or an off the shelf ticket system (Atlassian JIRA) and others just use a spreadsheet… gasp.

Sometimes all you need is a simple web application that all the participants can use to enter any ANY of the ideas that came up.  Even things like “The buttons should be colored blue.”  I needed a simple project to help me learn some technologies that are new to me.  Hence the “Backlogger” was born.  The whiteboard above shows the original concept.

Technologies used in Backlogger

  • JavaScript
  • NodeJS
  • Bootstrap
  • Mongo without the headache, neDB
  • jsGrid

Design Requirements

The design requirements were meant to be simple as possible to make this project something that could be done quickly.  They also needed to be flexible to allow for better learning.

  • Single Page Application
  • Open Source
  • No user logins, just a password, we are a big happy family
  • Self-contained application, no need for outside services or servers
  • Mongo database and Mongo queries
  • Allow for a maintainable list of people names who contributed ideas to the backlog
  • Allow for a maintainable list of functional areas to help groups the ideas
  • One time entry of an idea, no editing,
  • The editing of an idea will be done during the grooming
  • Filters that help find ideas quickly
  • Ability to backup and wipe the database (Mongo Documents)
  • Simple report that can be printed directly

GeekMustHave would like to thank Phoenix Learning Labs for the resources and funding to do this project.  GeekMustHave would also like to thank the MDHHS-DWIP team for the testing and feedback.

Open source, common components

What does it look like?


Backlogger is an Open Source project available on Github.


I’ve used “Backlogger” in one project so far but others who have seen it have expressed some interest in it.  That’s another reason why it’s Open Source.

Depending on the feedback I might do additional updates.  Maybe I need a “Backlogger” for the “Backlogger”?