Python Asteroids+Invaders on GitHub

I think about screen layout. I look at the list of things to do. It’s the Jira Trap!! It all seems so reasonable … until it isn’t.

These yaks aren’t going to shave themselves.

Despite all the arithmetic, both mental and machine-aided, my screen layout doesn’t look quite like the original. I’ve taken some pics for comparison. I’ll do some more comparing and figuring to see if I can see what I’ve done wrong. I think we have the spirit of the game pretty well captured, but my product owner really wants it to be more precise in layout. There’s no explaining these people.

Real Work

It occurs to me to add “Sound” to my little “Jira” tab in PyCharm. After that, the top three items in my new little file are:

  1. Saucer
  2. Two Players
  3. Sound

The rest looks to me to be just notes on things to clean up.

Perhaps we should separate out product improvement things vs code improvement.

Jira Trap!!!!

I really was thinking about improving my little Jira file for a moment, and it’s wrong, so wrong. It’s the Jira Trap! Next thing you know, I’ll be working up an SQL-based database with eleventy-seven fields and twenty-one different reports, hosted on several international cloud services. And worst of all is the notion of separating “product improvement” from “code improvement”. That invites one’s management and product people to start making priority decisions, choosing between features and improving the code.

The code belongs to the developers.
The product belongs to management.

I would never, ever, ever again, delegate my coding and design responsibilities to a manager, a product manager, or really anyone but the programming team. I would have our practice be that we make note of things that need improvement, and when we are working in a product area that needs code improvement, we’ll improve the code. No questions asked, just do what needs to be done.

Tiny Jira Trap!!

Is my simple Jira tab in the source code a mistake? It could be. I’ve already spent time formatting it, breaking it up into four headings, Program, Done, No, and Study. I’ve spent time moving the lines up and down in the lists, and allowing PyCharm to renumber the numbers. Heck, I could have saved time by using an unordered list instead of an ordered list, so that PyCharm didn’t tempt me into renumbering. After all, Markdown can renumber in the article anyway.

Planning and remembering are not product!

Planning is important. Remembering things that need doing is often important. But planning and remembering are not product. Those activities are inherently waste: if we could get as good a product without them, we wouldn’t do them.

Time spent with Jira, or your numbered lists, or your box of cards, is waste. The Jira trap is a deep one, it is easy to fall into, and it is hard to get out of.


I’m going to end this article right here, in the hope that in its shortness it may be useful to some folx.

Am I really saying that Jira and its cousins are a bad idea? Perhaps I am. I once got fired on the first morning of a week-long gig for saying that to the team in front of the boss. And I’d do it again, although more gently: I could have used the money, and the team lost four days of opportunities to think about improvement.

There is no doubt that planning and the use of planning tools is waste. It may be necessary waste, but quite often it is unnecessary waste, in that the same or better results could be obtained via more efficient means of making decisions and getting information.

Our product only improves when our development team make changes to the code.

All the planning, thinking, deciding, testing, reporting, advising, making use of highly-paid consultants … those things may improve what the development team does, but the product only gets better when they change the code.

Accordingly, the more quickly we can get the team to pick up the next item and do it, the better we’ll do, given that the next item is well-chosen and well understood by the team. Is Jira or your local equivalent really the fastest, most effective, most efficient way of getting the developers working effectively on the next thing we need?

Quite possibly it is not. You know my opinion by now, I hope. Now you get to think about that, and decide.