Category Archives: Software Development

Tech Debt in a 3 Month Old Project

I’ve been working on a new web app since October. The backend is a GraphQL API on top of a database schema. Each entry point unpacks the request and then calls a function that queries or mutates the database. There are some complex mutations—ones where there might be updates, inserts, and deletions that all need to succeed or fail together.

I know that I’m supposed to do this with transactions, but I was also using an ORM that I’m not very familiar with, and wanted to make progress quickly. I decided to pay lip-service to transactions, wrap some functions in them to indicate to myself that I needed to think about them, but mostly just ignore them. I would never not do transactions in a production app, but for this, it made sense.

After MVP, a month or so ago, I’ve just been adding minor things while my partner onboards some trial users. Eventually, I tried to implement a feature where the API call could result in many inserts and deletions, and I could see in tests that I could cause this to fail in ways that corrupted the data.

So, I had to stop, learn how to do transactions in this ORM, and then implement them in my data code. It took a few hours, and now the debt is paid off.

I do this kind of short-term borrowing/paying of debt all of the time. I am borrowing to keep myself in flow. I try to keep the debt top-of-mind by making it very evident in the code. It’s like using a credit card where you pay it off inside the grace period.

Be Skeptical of Points-based Productivity Claims

I do not personally use Story Points in my estimates because I know that everyone outside of development will translate them to time and I want to do that for them.

But, consider this claim: Adopting GitHub Copilot will increase productivity by 20%. I actually believe that to be true, but can you show it with Points? No, you cannot.

Here’s how it should go

  1. You do 10 sprints, you see that you have a steady state velocity of 100 Points
  2. You introduce GitHub Copilot
  3. Maybe for 2 sprints, you see velocity go up because developers over-estimate their stories. Let’s say it’s 120 now. Better report that quick, because …
  4. Then, devs start to adjust their estimates and velocity goes back to where it was.

Productivity went up, but velocity should stay constant because points are just time. You don’t get more time because of productivity gains.

If you see sustained velocity improvements (without changing the number of team members), then I would suspect gaming or a misunderstanding of how points are supposed to work.

Points and Velocity are best for front-line managers to understand what is going on with their teams and to size sprints. They should not be reported outside of the team, because they will be misunderstood and misapplied.

Making My Own CMS Worked Out in the End

In 2013 I started App-o-Mat to host content I was creating to teach iOS Development.

App-o-Mat is a totally custom CMS built with Django and Python that I have kept up to date for 10 years. It has been migrated from version to version of Django, from Python 2.x to 3.x, and I just recently replaced all of the Bootstrap with Tailwind.

I had learned Django in 2006, which is also when I learned Python. At the time, Ruby and Rails was probably the more obvious choice, but I’m actually glad I chose Python. Python has proven to be more enduring and useful in more contexts (e.g. AI).

From 2013 to 2021, I was full-time on iOS Development. App-o-Mat was the only web development I did. But, now all of the things I want to make are either for the web or best to be done in Python.

I know that making your own CMS is kind of nuts, but if I didn’t do that I wouldn’t know Python and my webdev knowledge would have atrophied. I think using some back-burner (non primary) tech stacks in side-projects might be a good idea—or it least it was for me.

Self-Hosting a Podcast: 2.5 Years Later

It’s been 2.5 years since I started working on a podcast and decided to self-host using the Blubrry WordPress Plugin and S3. Here are my original reasons and current thinking:

  • “I want the episodes to be available indefinitely, even if I stop making new ones“: This worked out great since I took a break for 2 years between episode 15 and 16. It would have felt bad paying a bill for something I wasn’t actively doing.
  • “I don’t want to pay for just hosting“: The key is “just hosting”. I think there are potentially a lot of things I (as an amateur podcaster) might like to pay for, but I didn’t see anyone offering something I cared about.
  • “I don’t care about analytics“: This is the main downside to self-hosting. I rolled my own analytics, but I’m not 100% sure they are correct. The problem is that to get anyone else to do your analytics, you have to send listeners to their URLs, which I am unwilling to do—partly because of the privacy leakage, but mostly because I value my URLs too much. I haven’t found this, but I’d like service I could upload weblogs to and get useful podcast-oriented analytics from.
  • “I have the skills and desire to learn how to self-host“: I don’t think you should self-host unless this is true for you.

Two years later, I can say that my system is easy to use and never requires any intervention to keep running. I never think about the reliability of S3 or Blubrry. My analytics scripts have needed tweaking, but that has mostly settled down.

Triangle Estimates

I estimate using time, not points. I do this even though I have mostly worked on product development teams inside of companies and not as a contractor for clients.

But, estimation on product development is not as high-stakes an activity as it is if you are billing based on it. The judgement of a successful product development project is based on whether it moves some business needle, not whether it was under budget. The margin on successful product development dwarfs reasonable overruns. There is also a lot of appetite for risk, where we know that we’ll win some and lose some.

That’s not true if the work is for clients. If they pay by the hour, they expect the estimate to be accurate. But there are very few (if any) big software projects that can be accurately estimated. When you’re wrong, you either have to eat it or have a very difficult conversation.

I don’t have a good answer, but I would start with triangle (or three-point) estimates. To use them, you estimate a most-likely estimate and then a best and worst case on either side. The three numbers describe a distribution (see the wikipedia page for how to combine them). The result is an estimate with a error range and a confidence interval. I would recommend sharing that instead of a single number.

The only task management system that I have seen that offers this option is DevStride, which carries three-point estimates throughout its system.

More Page-o-Mat Updates

I am working on making some books for Amazon KDP using Page-o-Mat, so that’s driving feature development right now.

I decided to create cover art using vector drawings, so I added the ability to add a list of drawing objects to a page. I currently support rectangles, ellipses, lines, text, and QR codes. Each object has keys to set stroke, fill, alpha, and other parameters.

A cover in KDP needs to be big enough to support the trim, bleed, and spine, so it ends up that page size is an arbitrary number. I had only supported standard sizes, like A5, Letter, etc. Now Page-o-Mat supports custom sizes and orientation.

I uploaded some books to KDP today. When they are approved, I’ll announce them here.

“What do you do?”

Just heard this template from The Art of Charm ep. 782 for how to answer “What do you do?” when you are meeting someone in a business context.

The idea is that you want to tell them something they can remember and repeat to the right person. So, you lead off with the kind of people you help, and then you say how you help them.

For me that’s something like: “I help B2B software companies by advising them on their product engineering.” I would somewhat alter that based on who exactly I was talking to (maybe niching down to fintech or mobile). It’s intentionally not very detailed to either invite questions or to let the conversation move on.

Later, if that person meets someone who works at a B2B software company that says something like “I wish I could get a handle on our developer productivity”, they might think of me.

Page-o-Mat Minor Update

I made a minor update to Page-o-Mat to add a few features I need for a journal I want to make.

New keys

  • subtitle: for adding a subtitle to a page. There are also the font, color, and alignment variants
  • show-title: a boolean that controls whether or not to show the title. You can use a string expression based on the page/section/variant indexes. This allows you to have a title that might only be on the first page of a section. (there is also show-subtitle)
  • footer-space: For lined journals, this allows you to have some blank space at the bottom. I also renamed heading to header-space, but support both for backwards compatibility (I believe that New Versions Should be Substitutable)

My plan is to use this to make a writing practice / morning pages journal with prompts (see my podcast episode Write While True Episode 19: Prompt Your Morning Pages for the rationale behind this).

Moore’s Law of Football

A few weeks ago, I wrote about what computing did to baseball, which was that it had doubled the number of stats they report every 18 months.

Right now, I am watching the Jets on Monday Night Football. It’s been a while since I tuned into a game live because I don’t live in NYC any more, so the Jets are hard to watch.

The thing that stands out to me is that there don’t seem to be any new stats. Maybe football really is just yards and points.

More likely is that there have advances in stats that help scouts, but the announcers have concluded that they are boring. They are right.

Pull Requests for One

I work alone on my programming projects, but I still make pull requests. I also review my PRs. It feels silly hitting the Approve button in BitBucket, and BitBucket knows that. It keeps warning me that my PR doesn’t have any external reviewers.

In 2003, the first year of this blog, I wrote about using Source Control for One, where I agreed with Eric Sink that source control was useful when working alone. It’s hard to think that there was a time when that would be non-obvious advice, but it wasn’t.

Today, in 2023, I think making PRs when working alone is probably common. I think that reviewing them isn’t. I’m not sure if I can convince you, but the reason I do it is that I keep finding problems. Also, it keeps me honest and makes sure that I keep Constructing PRs to Make Reviewing Easy.