Jonathan's Blog

Jonathan's Blog

Mindful Leadership and Technology (Mostly Software)

TagSoftware Development

Rebuild Application Rebuild Software Development

Software Rewrite/ Rebuild/ Re-engineer

Posted on .

Oh no. Another rebuild article.

Oh, yes!

We're currently having some discussion about what to call this process (Rewrite? Rebuild? Re-engineer?) On the new Exadel website. I'm partial to Rebuild, but I think that Re-engineer is likely to win.

In my relentless pursuit of information on this topic, I'm compiling a list of articles related to it.

Read these before you start a project like this:

I have published #3 before, but it is definitely worth a second post.


Software Estimate Software Development Technology Leadership

Estimating Software #1

Posted on .

Software estimates are out of fashion.

In spite of being out of fashion, many of us are asked (often for very good business reasons) to provide them.

Right or wrong, there are situations where you should not provide an estimate. I learned these the hard way, here are the ones I know:

  1. R&D work
  2. Highly complicated things you've never done before (even if you're 99% sure you can do them).
  3. Things you can't break down into small pieces
  4. System integrations where you don't control the flow of development (A vendor needs you to attend 10 meetings and then they want to certify your 1 line of code.)
  5. System integrations where the system is still being developed or tested (Here's a great question I've learned to ask over the years: 'How many other people have used this API before?').
  6. Collaborative Development - two teams working together, especially for the first time.
  7. Co-development - sometimes this manifests itself as #5, but it can be other things, like working with an outside vendor in a novel way on the same codebase.

Pretty much everything else is feature work and you can estimate that. It might be a little scary or intimidating, but you can.

I don't mean to suggest there is anything wrong with the things the 7 categories above. Those things can be very important work that needs to get done, and those things might be very fun work (if you can get it).

But, fun as it may be, you really shouldn't estimate it.

Here's what to do with those 7 items above - don't estimate them. Break them out into separate subsystems or budgets or categories. Whatever you use to segregate work, put them in their own place and create visibility to how the work is progressing.

Some clients/bosses won't like it, but they also won't like budget/timeline overruns with no explanation either.

Make it clear up front. Use your estimate (or non-estimate in this case) to communicate and set expectations. Then use it to reset them later if you need to.

Many bosses/clients will appreciate the effort you put into managing the simpler parts. And they'll appreciate that you understand how to separate more complex things from the typical or mundane.


Rebuild Application Rebuild Software Development

Application Rebuilds - A Micro-Service Approach

Posted on .

In some recent research I came across this post from Ben Martin:

It's definitely something you should consider when considering your approach to an application rebuild. It has a high value for risk mitigation.

I will definitely put this in the bag of tricks for approach on rebuild projects. I can see a lot of situations where it would be valuable.

I can also see a lot of clients who won't go for it, but that doesn't mean it isn't useful.

Even ruling it out as an approach will have value to many projects. Offering it allows you to say it was there, but removed from consideration. This will help make it clear that the large, monolithic project approach (and related challenges) was explicitly selected.


Technology Software Development Software CMS Contentful


Posted on .

Oh Contentful, where have you been all these years?

I wish this existed 5 years ago. It would have been helpful for so many clients.

Well, it is here now. And it is pretty great. Check it out.


Software Development Technology Technology Management

The City and Its Plumbing

Posted on .

When building your city you should not view the city-design part as a way to solve your plumbing problems. Not if you want someone to live there, anyway.

Nor should you build a city for which plumbing cannot be designed.

But rather, in your dream, in your vision of what a city should be, consider that you will still need plumbing and it shouldn't cost a million dollars to fix a leaky faucet.

Beyond that, the plumbing shouldn't be much of a consideration, unless you are building a city for plumbers.


Bots Conversational UI Slack Software Development Accoutability

Bots Rising - Part 6

Posted on .

Our internal bot has been running for a while and getting some use.

We've gotten it so that it runs for 7 - 10 days without issue, but after that length of time it seems to quietly lose the connection and we previously weren't checking for that. I'm not sure if that is a feature of Slack itself or the library we're using. In any case, 7 - 10 days seems pretty good and we should probably add some code to recover if something happens.

To get to 7 - 10 days with a Slack bot, the key was to use the Ping/Pong functionality you can see here. It's part way down the page, just look for 'pong'.

We're currently pinging every 10 minutes. This is a lot less than I've seen recommended, but I believe those recommendations were based on building chat clients with the RTM API, not long-running bots with lots of downtime. I don't want to get in trouble with Slack for sending a million ping messages for no reason.

Instead of upping the number of pings we send (which may have helped) we've added some functionality to check as part of our ping/pong functionality to check for the health of the connection. This seems to be the more responsible way to run the health check and reconnect if the connection is offline.

We've tested our reconnect, which works well. Now we just need to wait 7-10 days to see the production failure occur and see if it recovers.