Menu

Sherman On Software.

When your SaaS Scaleup can't scale, I can help

Blog Posts

The Never Rewrite Podcast, Episode Fifty-One, How Company Culture Impacts Code Delivery

In podcastTags Publish Date8 ViewsLeave a comment jeffpsherman

Company culture can have a significant impact on the style of code delivery. A rigid and bottlenecked code review process can slow down code delivery and create frustration. Alternatively, an open and collaborative culture can lead to faster and more efficient code delivery. It is important to strike a balance between code quality and speed of delivery. Perfect code that doesn't solve the problem is not useful, while imperfect code that is easy to change and improve can be valuable. When considering a job, it is important to ask about the company's code delivery style and whether there is a culture of collaboration and openness.

Takeaways:

  • A rigid and bottlenecked code review process can slow down code delivery
  • A collaborative and open culture can lead to faster and more efficient code delivery
  • Striking a balance between code quality and speed of delivery is important
  • Imperfect code that is easy to change and improve can be valuable
  • When considering a job, ask about the company's code delivery style and culture

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

Four Patterns Of Data Loading

In software designTags , Publish Date74 ViewsLeave a comment jeffpsherman

There are two main questions to consider when loading data from a database or other external system:

  1. Should I load the data at the start, or when I need it?
  2. Once I have the data, should I save it for reuse?

The answers to these questions give you the four patterns of data loading:

  1. Lazy Load - Load as needed, don’t reuse
  2. Pre-Fetch - Load at the beginning, don’t reuse
  3. Read Through Cache - Load as needed, save the results for reuse
  4. Pre-Cache - Load all the data at the beginning

Each pattern has pros and cons:

Picking the right, or wrong, pattern for you use case can have major performance and scaling implications.

These are the main questions to ask yourself:

  • How often does the data change?
  • How important is the performance of the code’s critical path?
  • How likely am I to reuse the data?
  • How much do I know about the data I need?

Frosting A Turd And Iterating To A Cupcake

In iterative deliveryTags Publish Date82 ViewsLeave a comment jeffpsherman

Recently a colleague described one of my plans as “Frosting a Turd and Iterating to a Cupcake.”

It was meant as a pejorative, but I was excited because he finally got it!

We were discussing a report.  We agreed that the current version was indeed a turd!

My colleague wanted a full rewrite; I was pushing for TheeSeeShipping, an iterative approach.

Should we build a new report with a new UI, or reskin (frost) the original report and iterate?

Should we tell customers that something new is coming, or show our progress and solicit their feedback?

When you have knowingly served turd to your customers, what are the odds that you can pick the right frosting and cupcake flavor?

How many turds are you willing to serve while you figure it out?

Frost the turd every time!

The Never Rewrite Podcast, Episode Fifty, Fulfilling Friday – Saving Customers Millions

In podcastTags Publish Date9 ViewsLeave a comment jeffpsherman

In our new series 'Fulfilling Fridays', Jeffrey shares a fulfilling software project he worked on at Guaranteed Rate, a mortgage broker company.

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

The Never Rewrite Podcast, Episode Forty-Nine, Falsehoods Programmers Believe About Projects Part 2

In podcastTags Publish Date16 ViewsLeave a comment jeffpsherman

Isaac and Jeffrey continue to discuss falsehoods that programmers believe about projects. They explore the misconception that the project will solve the stated problem, highlighting instances where the delivered software did not actually solve the problem. They also discuss the importance of understanding how the user will use the software and the need for clear communication and feedback loops to ensure that the project is on track. They emphasize that the success of a project is not solely determined by the software, but also by factors such as the alignment of project goals and the availability of resources. Overall, they highlight the need for critical thinking and continuous communication to avoid common pitfalls in project development.

Takeaways:

  • The project may not always solve the stated problem, even if the software is delivered as requested.
  • Understanding how the user will use the software is crucial for building a useful and successful product.
  • Clear communication and feedback loops are essential to ensure that the project is on track and aligned with the user's needs.
  • The success of a project is not solely determined by the software, but also by factors such as project goals and available resources.

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

Fixing All The Bugs Won’t Solve All The Problems – Deming’s Path Of Frustration

In software designTags Publish Date7707 ViewsLeave a comment jeffpsherman

A program of improvement sets off with enthusiasm, exhortations, revival meetings, posts, pledges.  Quality becomes a religion.  Quality as measured by results of inspection at final audit shows at first dramatic improvement, better and better by the month.  Everyone expects the path of improvement to continue along the dotted line.

Instead, success grinds to a halt.  At best, the curve levels off.  It may even turn upward.  Despondence sets in.  The management naturally become worried.  They plead, beg, beseech, implore, pray, entreat, supplicate heads of the organizations involved in production and assembly, with taunts, harassment, threads, based on the awful truth that if there be not substantial improvement, and soon, we shall be out of business.

W. Edwards Deming, Out of the crisis, Page 276

In software, as in manufacturing, some problems occur due to bugs or “special causes”, and some are “common cause” due to the nature of the system’s design and implementation.  Fixing bugs is removing special causes.  Removing bugs greatly improves software quality, but it won’t impact “common cause” issues.

Some “common cause” software performance issues I have encountered:

  • The software is “in the cloud”, but really it is in one data center in the US.  As a result the software is slow and laggy for customers in Europe and Asia.
  • The software runs slowly because the hardware is underprovisioned.
  • The software runs slowly because large amounts of unnecessary data are being sent to the users.
  • The software runs slowly because of inefficient data access patterns.

Even with no bugs, “common cause” issues can result in low quality software.  

The way off of Deming’s Path Of Frustration is to attack system design and implementation issues with the same fervor used to fight bugs.

The Never Rewrite Podcast, Episode Forty-Eight, Falsehoods Programmers Believe About Projects

In podcastTags Publish Date78 ViewsLeave a comment jeffpsherman

In this episode, Isaac and Jeffrey discuss falsehoods that programmers believe about projects. They explore assumptions such as projects having defined beginnings and endings, the role of priorities in project work, and the importance of clear communication and feedback. They also touch on the challenges of working on successful projects that transition into ongoing maintenance and the consequences of failed projects that continue to exist. The conversation highlights the need for programmers to question these assumptions and adapt their approach to project management.

This episode is a supplement to my post about Falsehoods Programmers Believe About Projects.

Takeaways:

  • Projects often don't have defined beginnings or endings, and assumptions about their start and end dates can lead to confusion and miscommunication.
  • Relying solely on personal priorities to determine when to start working on a project can lead to conflicts and misunderstandings with others who have different priorities.
  • Clear communication and feedback are crucial in project work to ensure everyone is on the same page and to avoid missed signals and mixed signals. - Programmers should be proactive in sharing their expertise and insights on projects, even if they haven't been explicitly asked, to prevent unnecessary rework and improve overall project outcomes.
  • Successful projects often transition into ongoing maintenance and feature development, while failed projects that are not fully turned off can continue to exist and incur costs.
  • Questioning assumptions and adapting project management approaches based on the specific context and circumstances of each project is essential for success.

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

Falsehoods Programmers Believe About Projects

In dev teams, software designTags Publish Date311 Views1 Comment jeffpsherman

Years ago, Patrick McKenzie, wrote an article titled Falsehoods Programmers Believe About Names.  The article inspired a short lived burst of other programming falsehoods.  This is a very late entry in the genre, covering incorrect assumptions about software projects.

All of these assumptions are wrong.  Try to make fewer of these assumptions when working on projects.  Since you are always working on projects at work, always be questioning your assumptions about projects.

  1. Projects have defined beginnings.
  2. Maybe not formal beginnings, but there is a point when you are supposed to start work.
  3. Your manager knows when you should start working.
  4. You can use your priorities to determine when you should start working.
  5. You should be working on the project because you were asked.
  6. You should not be working on the project because you weren’t asked.
  7. Projects have defined endings.
  8. Successful projects have endings.
  9. Failed projects have endings.
  10. The project will solve the problem.
  11. The project will solve a problem.
  12. The project won’t make the problem worse.
  13. Everyone on the project agrees on what problems the project is supposed to solve.
  14. Everyone agrees about what solving the problems means.
  15. Solving the problem will make the project a success.
  16. Not solving the problem will make the project a failure. 
  17. There is a relationship between the project’s success and the status of the problem.
  18. The software you are asked to write will solve the problem.
  19. The software you are asked to write will make the project a success.
  20. Writing the software you are asked to write means you are doing a good job.

At best, projects are best guesses by well intended people.  At their worst, projects can become meaningless busywork that is completely unrelated to any problems or desires at a company.  The fewer false assumptions you buy into the more effective you will be. 

The Never Rewrite Podcast, Episode Forty-Seven, Maintenance Work as a Flight to Safety – A Manager’s Perspective

In podcastTags Publish Date30 ViewsLeave a comment jeffpsherman

Isaac and Jeffrey discuss the flight to maintenance work as a safety option from the manager's perspective. They explore different perspectives on maintenance work and the value of taking on such work. They emphasize the importance of understanding the reality of the system and approaching maintenance work as an opportunity to solve real problems. They also discuss the role of accountability and changing the culture around maintenance work. The episode concludes with a discussion on the impact of not addressing maintenance work and the benefits of going slow to go fast.

Takeaways:

  • Maintenance work should not be viewed as a punishment, but as an opportunity to solve real problems and make teammates' lives easier.
  • Understanding the reality of the system and addressing maintenance work can have a positive impact on the team's morale and productivity.
  • Managers should create a culture of accountability and ensure that support and maintenance issues are fixed, not just mitigated.

Watch on YouTube or listen to it at NeverRewrite, Spotify, Apple Podcasts, or Amazon Music, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!

Convincing People Not To Touch Hot Stoves Is Easy

In iterative deliveryTags Publish Date148 ViewsLeave a comment jeffpsherman

The hard part is convincing people that what they’re reaching for is a hot stove.

Having developers work for 6 months and then do a single release is appealing because development proceeds in the straightest line over the shortest distance.  When I push for small releases and iteration, the main pushback is that the incremental releases add work.  The tradeoff appears to be one release after 6 months, or 7 monthly releases.

Seven months is more than six months, so iteration is more work!

The problem is that the single release after 6 months of work is “hot stove”.  It’s a plan that needs the requirements to be perfect at the start.  Nothing new can be learned during the project.  Customers and the market have to remain exactly the same.  It’s a plan that will leave you burned.

It isn’t six months versus seven months.  It is 6 months, plus 3-6 months of rework versus seven months.

Explaining the risks is ineffective.  People will agree that if the plan is wrong, that if we learn new things, or if the market changes then of course a 6 month plan will end up delivering the wrong thing.  Of course you will then need another 3 months to correct.  That’s obvious.

After agreeing about the risk, they will then declare that those risks don’t apply to THIS project.  This project isn’t at all like those “hot stoves”.  This project plan is correct and everything has been considered.

Describing the danger doesn’t work if the problem doesn’t resonate with the listener.  Instead of urging people not to touch hot stoves, work on helping them identify the hot stove.

  • Instead of talking about the risks of a single release, talk about the value of iteration.
  • Don’t talk about the likelihood that the new workflows aren’t perfect, talk about the value of early customer feedback.
  • Don’t talk about the risk that the 3rd party system doesn’t really work like their spec, talk about the value of early integration.
  • Don’t talk about holding back valuable features for a gigantic release, talk about delivering value to customers.

Once people see the risk and the tradeoffs, you won’t have to convince them not to burn themselves.  After all, everyone understands that you shouldn’t touch hot stoves.

Older Posts

Site Footer