"The Cobbler's Children have no Shoes"

There is an old phrase, it has appeared in different forms in perhaps a dozen languages, but the sentiment is all the same: Since you do a thing for a living, 'someday' you will do the thing properly for yourself and your family, but right now, you save all your best effort for your customers.

We Are All the Cobbler's Children

In software, we also save our best work for our customers. Unfortunately we also use software to make software. "Someday" rarely comes, and for decades some of the most maladapted pieces of software you could encounter were developer tools. Good Enough has ruled the day for a long time, and only in recent years have things changed in any perceptible manner.

The problem with this is that humans negotiate, all the time, even when we don't think we are. We tend to adjust our expectations to what is going on around us. Those "Would you spent $1000 for this?" commercials bank on this tendency. It's called Anchoring. Our belief is that if you use awful tools while trying to make something great, you won't do your best work.

How you can help

I am looking for like-minded individuals. People who understand the multiplicative effect on productivity that a good tool offers, and the subtle ways that an otherwise good tool can undo its own advantages. I'd like to find other people who count the cost of using their tools against the 'accidental complexity' of their projects and are highly motivated to find better options or make improvements to existing ones.

What I hope to do is create a small group of people, probably full stack developers, who understand Human Factors but can also contribute substantially to tools development. I'm hoping to organize people to identify developer tools that are already in the range of Good Enough to 'fairly decent' and collaborate to fix them. And also to identify other tools that need better alternatives and work together to create them or help people who can.

If you'd like to help, check out the list of projects below, or suggest a new one.

What We're Working On

See the full list on our GitHub organization page, but here are the highlights.

New Generation Project Management Tools

Virtually every single project management tool currently in existence was designed before CI/CD became widespread. They all keep it at arm's length instead of inviting it in. In a very Paradox of Choice sense, some of my best experiences with a PM tool were with Trac - a dead simple but highly integrated management tool. We seek to build something on this philosophy, leveraging CI/CD concepts, and modern visualization tools.

Production-Ready Frameworks

The HEW Projects.

For ease of development, many libraries come configured in a very easy to start manner. Some say the user should know better, others claim the code should be secure by default. The argument is always an either-or scenario.

In an active community the definition of 'correct configuration' changes over time. A project generator may help keep new developers safe, but create challenges for existing users. In place of generators we propose leveraging underutilized features of DCVS tools such as Git, creating simple Git repositories that can be forked, so that users can periodically merge changes from the upstream repository to stay in sync. Getting the base project correct out of the box becomes a group effort, rather than down to each team.

This structure also works well wonderfully in a microservices or other non-monolithic architecture. Getting headers, logging, failure behaviors, stat collection, correlationIDs, and load balancing right once, and copying it across projects using Git, rather than by hand.

CommonMark

In the world of Wiki and Markdown, fragmentation has always been a problem. In the interests of easing that learning curve we support Jeff Atwood and his friends' attempts to create CommonMark, and to create new ways of teaching simplified markup to new people.

As the world has become more and more computerized, we have moved on from solving purely technological problems to trying to organize information and people to deal with social, political, environmental, and health issues. This now often involves gathering ('crowdsourcing') short prose from experts. While this is changing over time, the fact of the matter is that there are many interesting and worthwhile problem domains where computer skill are not highly valued, and those with the deepest expertise or the most interesting experiences are still often not particularly computer savvy, and have no interest in becoming so.

We are also working with markdown learning tools such as commonmarkify, which is our CommonMark adaptation of the markdownify project, a hybrid MarkDown editor that formats the source markup in a style similar to the final output.

Other Avenues

In addition to these projects, we have some other ideas we'd love to work on.

Multi-device programming

We are fast approaching a world where only technologists own fast computers. In the early 90's a "Developer Grade Machine" could easily run you $8000 in inflation-adjusted dollars. Today you can have a similar machine, often for much less than $2000. But with everyone migrating to tablets and smart phones we might not be able to enjoy those economies of scale for much longer. There may come a day when developers are buying gamer machines or server grade hardware because nothing else exists.

At the same time we have all of these internet gadgets, and unless we are specifically developing software for them we do not benefit from them in our daily coding, and when they become too antiquated we have no use for them at all, even though they could work as an auxiliary display. We would like to see these devices applied to greater use:

Safe by Design Libraries

The internet is rife with articles proclaiming the Top 10 Mistakes in Problem Domain X, in which they enumerate the common or even clichéd manner in which we as developers often manage to produce the same classes of errors in our code. We believe that rather than indicating a moral failure by the user that it is instead due to Human Factors in the API design. As the number of libraries we use increases, this work will become much more important.

Most APIs are filled with low level details and false friend functions which harm the obviousness of a piece of code. We believe in the idea that there can and should be Safe by Design alternatives to these tools in which code is Obviously Correct or Obviously Incorrect. Some areas we wish to apply this principle to are:

Using Docker to Run Selenium Tests on Jenkins

Running Selenium in Docker is supported by the Selenium Team, and is a great way to run tests locally without worrying about an errant keystroke causing your tests to fail. This docker-compose script can be used to run Selenium tests on your CI server, which is typically a headless environment. This also supports remote observation of a Selenium run, an important debugging option that is often overlooked.

This project, 'docker-jenkins' is just a small set of scripts to combine work done by the Jenkins community with work done by the Selenium community into something that is interesting and useful in its own right.