Menu

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

Tag: software development

AI First API Strategy

In iterative delivery, software designTags , Publish Date237 ViewsLeave a comment jeffpsherman

What does BYO-AI mean for your company’s API strategy?

This article goes into the obvious, and subtle, changes that need to happen to support customers bringing their own AI.

All Features Need To Be Fully API Accessible

AI can only interact with publicly facing endpoints.  Any feature that isn’t publicly facing, or is only accessible through the UI, isn’t accessible to your customer’s AI.

Embracing your customer’s use of AI means making all of your features publicly available.  Now is time to reevaluate past decisions about excluding features for performance, scalability, security, pricing, and other reasons.

Customers come to you with problems and AI opens up entirely new avenues for solutions; but only if you let AI into your API.

All Features Need To Be Documented

AI is going to learn about your API by reading the docs, reading the example code, and then reading StackOverflow.

If you want AI to do a good job writing code against your API, you need to do a good job telling it how.  Undocumented endpoints, missing parameters, and bad code examples make that harder.

Outdated docs and libraries need to be scrubbed from the internet.  It is very much like hiring a reputation company to ensure that what AI sees and knows about your API is what you want it to see and know.

Technical writers and other DevRel positions are notoriously understaffed.  This is a great time to hire talented writers and get them writing for AI instead of human readers.

Features and Docs are the Easy Part

Fleshing out your API and producing up to date, readable docs are things you should have been doing all along anyway.  AI doesn’t change that, it merely raises the cost of poor software hygiene.

Once you get the table stakes out of the way, things get harder.  Or at least take more effort.

Assume That AI Has No Idea What It Is Doing

AI is the ultimate expression of the developer attitude, “I don’t want to understand the business, I just want to code.”  AI can’t understand the context and the customer can’t understand code.  This model works out because this is sort of how most software is written anyway.

These are the conceptual shifts you need to make with your API to support AI development.

Make Your API Simple and Verifiable

Users are going to manually confirm API actions through the UI so your API needs to be simple and easy to verify.  Endpoints that take multiple, open ended collections are great for performance and pushing a lot of data.  

If they can partially succeed, customers will find them a nightmare as they try to understand the results of the AI’s code.

Lean on strong validation, all or nothing changes, and understandable error responses.

Things Are Going To Be Rerun.  A Lot.

Everything will end up being rerun.  Customers won’t understand data models and won’t understand the risks with rerunning things.  

Embrace it by making everything as idempotent as possible.  

Make non-idempotent actions all-or-nothing.  AI is going to get close, a lot.  The last thing your customers expect is for all that flailing to wreck their data.  Bias the endpoints to either fully succeed or to take no action.  Don’t do partial updates and then bail on the request.  Change your processing to do full validation, and make changes only when you know you can make the full change.

Idempotent and all-or-nothing can be shockingly hard changes to implement.  Fortunately, you can iteratively improve your API!

Error Messages Need To Be Non-Developer Readable

Put effort into making your errors human readable and reasonable.  AI is better at grokking text than dense error responses.

Even better, when something fails validation include a link to the documentation where you’ve explained the correct structure.

Shifting to An AI First API Takes Time

Shifting to an AI first API isn’t complicated, but it will take time and effort.

Start with the fundamentals - make all of your features available through your API, and get your documentation up to date.  Then, if need be, work to make you API AI friendly.

Customers are going to bring their own AI to your API and do amazing new things that you would never have imagined.  Embrace the change.

First, AI will do unprofitable programming work

In software designTags , Publish Date325 Views1 Comment jeffpsherman

In a recent episode of NeverRewrite, Isaac and I discussed the implications of AI doing rewrites for developers.  

So what if things change?

AI will probably replace most of the coding that developers do day-to-day today.  Today’s developers don’t punch punch cards, don’t design circuits, or write assembly code.  The nature of development has changed in the past, and will change in the future.

The first killer app for the PC was Lotus 1-2-3, which made spreadsheets widely accessible.  People used Lotus to perform a lot of accounting functions, but we still have accounting software.  Spreadsheets didn’t replace special function software, they created a new category of general purpose tools.

Rather than eating software development jobs, AI is a general purpose tool that will enable an explosion of software at the unprofitable low end.

What is The Unprofitable Low End of Software Development?

Simply, software developers are expensive.  There is a lot of potential software that could be written, but wouldn’t be profitable enough to hire someone to write.  There are tons of single use, single purpose tasks that could be replaced with a small bit of code, but only if you happened to have a developer nearby.

No Code / Low Code solutions help narrow the gap, but there are tons of tasks that are still too small to be generalized.

For example, I recently took a 3,500 product catalog in CSV form and wrote some python to upload the products to Shopify.  It also performed a second step to pull in the images from the factory’s website and associated them with the new products.  Shopify has great tools, uploading the file would be easy, but adding the images would have been a daunting and dull manual task.

Easy for a developer though; I ran it once, and will probably never touch the code again.

Trust, When You Can Verify

AI can write mostly correct code today.  When you can verify the results, you can accept them.

In the Shopify example you can verify by checking to see how many products were created.  You can check to see if they have images.  If it showed up on Shopify, then the software is correct.  It is running locally so performance and security pretty much don’t matter.  Optimized string functions and defensive string escaping aren’t concerns when you are only dealing with one file, once.

Prediction: AI Will Increase API Usage

As a development tool, AI will turn the average user into a mediocre API developer.  There will be an explosion of non-technical people using company’s APIs to solve bespoke problems in ways that couldn’t be done profitably before AI.  This won’t reduce the need for developers, it will increase the demand for people who can write APIs that are resilient, performant and secure.

Expect a flood of customers using your API in ways you couldn’t imagine.  The question isn’t how to have AI write code for your company, the question is how to make it easy for AI to use your API.

I can’t wait to see what people come up with!

The Grand Reveal Violates The SaaS Business Model

In crm, iterative deliveryTags , , Publish Date331 Views2 Comments jeffpsherman

Apple is legendary for the Grand Reveal.  Steve Jobs would say “Just one more thing” and then reveal an entirely new category of device or software.  It was amazing theatrics, shot Apple into the stratosphere, and cemented The Grand Reveal as a technology marketing tactic.

But for a SaaS The Grand Reveal violates a key principal: customers always have the latest software.  Holding back months of development and new features in order to create an exciting reveal breaks that promise.

Anytime you’re considering holding back a feature to create buzz ask yourself, does this delay help my existing customers?  You have customers that have already trusted you by buying subscriptions in exchange for the latest software.  Is it fair to hold back, to devalue the service, in order to market to new customers?

Of course not!

As a SaaS you’ve promised customers that they will always have the latest software.  Holding back breaks your promise.  Never hold back from your existing customers to market to new ones.  

Always be releasing!

How Understanding Business Strategy Helps Developers Prioritize Projects

In Cross PostTags Publish Date87 ViewsLeave a comment jeffpsherman

Understanding your company’s business strategy will help you battle analysis paralysis to find the right projects for your org.

In my latest article at leaddev.com you will learn about the three types of business strategies, how to learn which one your company is pursuing, and how to apply them to your work to ensure that all of your projects add value.

Would you like to hear more about understanding business concepts and metrics for developers? I think this is an important and under represented topic; I'd love to hear your feedback!

Phase 1 is a Millstone not a Milestone

In iterative delivery, software designTags , Publish Date430 ViewsLeave a comment jeffpsherman

Metaphorically, milestones are markers on your transformation from one state to another.  Millstones are useless, heavy, burdens that you can’t put down.

Project plans that seek to set out project milestones often end up burdening themselves with millstones.  The mistake is confusing the transformation with the project.  Millstones track the journey, milestones track the destination.

Things like “Phase 1” can’t be a milestone because there is no guarantee that completing Phase 1 means that you’ve made any progress towards your goal.  Yes, you worked hard and delivered a lot of code.  You’ve done the things you said you would do when you originally planned the project.  Can you objectively show that you’re closer to your destination?

Milestones, by contrast, are objective, external, measures of progress.  “Customers can use a feature” is a milestone.  “First paying customer” is a milestone.  They are points you expect to cross during the transformation because they demonstrate progress.  You can declare that some milestones are irrelevant, you can set new milestones, but you can’t move the milestones themselves.

Project based millstones like Phase 1 encourage movement and gaming to meet artificial deadlines.  Can’t complete a feature in time, just move it to Phase 2 and keep the project on track.  Phase 1 encourages wasteful death marches so that developers and project managers can report that the project is moving forward.

You can put down your millstones wherever and whenever you want.  Makes no difference to anyone or anything other than the artificial constraints you put on your project.  Today is a great time to let go of the weight.

Two Paths For Paying Down Tech Debt

In iterative delivery, software designTags Publish Date396 ViewsLeave a comment jeffpsherman

In my last post I discussed two ways of making Tech Debt an expensive problem that gets fixed.  

I was trying to show that a rewrite or major project requires proving that the problem is very large, and convincing leadership that you can solve it in a cost effective manner.  A key piece is that the problem must be large to justify fixing it.  Rewrites and projects encourage you to raise the stakes to create urgency and justify the costs.

Iterative Delivery is about lowering the stakes.  The stakes are low, the urgency is low, and the costs are low.  You can “just do it” by adding a few hours onto your regular development cycle.  Instead of needing to convince leadership it would be strange to mention it all.  The stakes are too low to bother them at all.

Here are the two paths as a flowchart:

TheeSeeShipping, iterative delivery, brings results faster.  Choosing this path will have you paying down technical debt while rewrite plans are still being written.

There is another major difference between the paths.  A rewrite requires you to complete the whole project before you can measure the impact.  You don’t get to know if your project was worthwhile after you have spent all the time and money.  Maximizing the stakes also maximizes the risk.

Iterative delivery gives you unlimited opportunity to evaluate progress and change course.  Some changes will be worthwhile, some won’t, and you get a chance to access and correct after each change.  The stakes are low and so is the risk.

Picking a rewrite over iterative delivery increases risk and delays results.

Tech Debt is a Big, But Not Expensive, Problem

In dev teams, iterative delivery, software designTags , Publish Date192 Views1 Comment jeffpsherman

A common mistake among developers and line managers is to mistake Tech Debt as an Expensive, instead of a Big, Problem.  For tech debt to be an Expensive Problem the CTO and VPs of Development have to believe that the value the company will get from paying down tech debt is greater than the cost.

Leadership doesn’t reject pitches for rewrites and other major initiatives to address tech debt because they don’t believe that Tech Debt is a Big Problem.  The initiatives get rejected because they don’t believe that the results will justify the cost.

There are two ways to get around the Big vs Expensive problem.

The first is to use data to prove that the problem is Expensive.  

Find a way to measure the costs of tech debt: lost developer time spent fixing bugs, increased developer time building new features and above average customer churn.  Then, find a way to estimate how much better things will be after the big initiative.  Finally, estimate how long the transformation will take.  If you can credibly show that the improvements are greater than the costs, you should have no problem getting your initiative approved.  

Remember though, that you’re estimating the value of the improvements and length of time.  Credibility is as much about leadership’s faith in your delivery as it is in the numbers.

The second way to get around the Big vs Expensive problem is TheeSeeShipping, aka Iterative Delivery.  

Make small improvements every release and show that the cost of the problem is shrinking over time.  Less time spent fixing bugs, faster feature development, maybe even a reduction in churn.  Demonstrate that Tech Debt is an Expensive Problem by fixing it and providing more value than cost.

You’ll find that you won’t have any trouble getting approval, because you won’t need any approval at all.  You just need to start.

The Rewrite Release Fear

In iterative deliveryTags , , , Publish Date192 ViewsLeave a comment jeffpsherman

Release Fear is a common killer of rewrite projects.  

As a rewrite comes closer to release, higher ups will start taking an interest in the project.  These leaders won’t have context on the myriad discussions and compromises that went into the rewrite.  Instead, they focus exclusively on lost features.  Value creation gets ignored and the release gets blocked in the name of existing functionality.

Is the missing functionality important?  Do the features outweigh the value that the rewrite brings to customers?  The team doing the work decided that these were good tradeoffs.  Loss Aversion ensures that leaders only see what was left out.

Adding the missing functionality comes at the cost of time and the value of the rewrite.  As costs go up, each revision makes the fear worse.  I have seen multiple projects, years of programmer time, fail because they could not be released to production until they could prove that the release would be perfect.

The alternative is to TheeSeeShip.  When you have 2 versions of the code you can have a discussion about which one should be in production.  When there is only one version, there’s nothing to discuss.

TheeSeeShip to keep the stakes low and Release Fear won’t be a problem.

Separating The Work Of Today From The Work of Tomorrow

In iterative delivery, software designTags , Publish Date298 ViewsLeave a comment jeffpsherman

Scaling software has tension between the needs of today and tomorrow.  How do you resolve the tension?  Where does the work of today end?  What makes the next step part of the work of tomorrow?

Consider this simple rule:

For any piece of software in your system, you should scale it when it is the primary constraint, and stop when a different part becomes the new primary constraint.

Easy to say, and easy to do…if you can measure the performance of your system in part and as a whole.

If you don’t know which piece of your software is failing to scale, if you’re guessing about the work of today, don’t be surprised when your scaling efforts don’t impact the system as a whole.  Sometimes the scaling work of today isn’t scaling, it’s observability.

Do The Hard Part First

In UncategorizedTags , Publish Date372 ViewsLeave a comment jeffpsherman

Seth Godin Posted:

The hard part first

If you’re trying to reduce risk, do the hard part first. That way, if it fails, you’ll have minimized your time and effort.

On the other hand, if you’re looking for buy-in and commitment so you can get through the hard part, do it last. People are terrible at ignoring sunk costs, and the early wins and identity shifts that come from the easy successes at the beginning will give you momentum as you go.

The hardest part of scaling a system is getting pieces of the current system to work with the new scaled out versions. Design and implementation are usually much more work, and take much more time.

Design and implementation don't involve working with the imperfections of past design and implementation. They don't have political agendas, and they aren't too busy to make the changes you need.

From my experience, the hardest part of any project built in isolation, is bringing the system from isolation to production. Whether you are bringing in a scaling framework, doing a rewrite, or building a new product; you and your team can write the software. You can shape it how you want or need because it is in isolation. Getting out of isolation requires changing your software to match production, and changing production is very hard.

Save yourself and your team, get your software into production from the beginning. Otherwise you may find yourself throwing away a year's worth of work because getting into production is the hard part.

Older Posts
Newer Posts

Site Footer