Saving Straight to Production

I'm a solo entrepreneur. I create custom AI solutions for my clients. I manage about 30 clients in total, and for a lot of these clients I am literally their entire software development department. I've got no program managers, no scrum masters, no interns or junior developers - Only me! My process for working is as follows:

1. The client sends me a PM
2. I ALT+TAB into their production code and solve their problem
3. I answer them "done" a couple of minutes later

For most requests I spend about 5 minutes in total from they send me a PM until the feature or bug fix is live in production. You can watch me implement a new feature for one of my clients in the following video.

If I was to follow all "best practices" related to software development, I'd end up with a process as follows:

1. The client requests a new feature or reports a bug
2. I send it to my program manager
3. My PM tests it to verify that it's a legitimate bug, and/or to verify it's a feature that we want to implement
4. My PM puts the request into his backlog
5. A couple of weeks later my entire software development team spends some 20 minutes discussing the request during their next grooming session, and decides if it should go into the next sprint
6. If it goes into the upcoming sprint, then at some point 3 to 4 weeks after the request was made by the client, a software developers pulls out the request and starts working on it
7. Since we're talking about a TDD software development model ("best practices") the developer creates a unit test that fails
8. The developer creates a view model, a database model, and configures AutoMapper to automatically map between these two different models
9. Then the developer creates an interface
10. Then the developer creates a service implementation
11. Then the developer needs to wire up his IoC container such that it resolves to my service implementation for instances of the interface
12. The developer needs to create a controller since the feature requires an HTTP endpoint
13. Since the feature is retrieving data from the database, he creates a handful of interfaces and a couple of classes, typically using maybe the repository pattern or something similar
14. Then possibly the developer needs to correctly configure our O/RM library since the feature is touching the database
15. The developer tests locally on his computer, for some 30 minutes, to test all possibly permutations - While verifying the feature is thoroughly unit tested, such that it has a coverage of its codebase of at least 80%
16. If the feature is not thoroughly unit tested, the developer needs to add more tests until coverage is at least 80%
17. Since this particular feature is touching the database, the developer needs to create some sort of mock object, since no unit tests should touch any networking or state to be considered "pure" and "good"
18. The developer then creates a branch and commits his changes to the branch before pushing
19. After the developer pushed, he needs to wait some 3 to 50 minutes before all pipelines are done executing, to verify the branch didn't bring in breaking changes, in addition to executing static code analysis tools to verify the code is given a grade of "A" on all important metrics
20. Then the developer needs to create a pull request, where he typically needs two other developers to approve his request before it's allowed to be merged into staging
21. These two confirming developers creates a couple of comments each, typically for spelling errors in the comments, and/or lack of comments, and the original developer needs to go back and revisit his or her code. This process repeats itself some 2 to 3 times before the pull request is finally accepted
22. The pull request is finally accepted, and merged into the staging branch
23. Merging into the staging branch triggers some 3 to 4 additional pipelines, taking some 40 more minutes, repeating basically everything that happened as the developer originally pushed towards upstream
24. After some 45 more minutes, it's deployed into staging, and the program manager can test. The program manager however is busy the whole day, so he can't find the time to test it before early next week
25. Next Monday the PM tests the code, and verifies it's working, before sending it to QA asking for a more thorough test
26. QA doesn't have the time to test this before next week, so another week passes, before finally Monday some roughly 6 weeks after the client asked for help it's finally quality assured by the QA team
27. The feature is merged into production, and some 7 weeks after making the original request the client finally has his feature or bug fixed

If you believe I'm exaggerating, realise I just described every single software development department I have ever worked in. And I have worked with a lot of software development departments. So our "best practices" took something that I can do personally in some roughly 5 minutes, and which I am doing in 5 minutes in the above video, and turned it into a 7 week long project, adding cognitive load to some 10 additional people, and in total spending some 50 hours of workload for the organisation as a whole.

If we imagine that each employee has a cost of $200 per hour in the above scenario, then my "saving straight to production" process costed my organisation roughly $16 in total. While our "best practices" costed another organisation some roughly $10,000 in total. And in the end, it's the same result. Nothing really changes for the client, except the client needs to pay $10,000 instead of $16.

"Best practices" have increased the cost of software development by a factor of 625

Am I the only one that thinks this is crazy?

Lean Development

Facts are that what you refer to as "agile software development" and "lean development" is about as rigid and complex as it's possible to come. Lean and agile software development in combination with "best practices" have made it almost impossible for us to do our jobs. To understand just how crazy our industry is, realise that this is my IDE.

The IDE was created by me, it's called Hyper IDE, and it's a web based IDE. Its purpose is to run directly on top of production code, such that when I click the above "Save" button, the code is saved directly into production. If I want to test the code, I click F5 and I get a dialog popup asking me to parametrise my invocation.

This allows me to test my code from within the same environment that I created the code. This is only possible because the runtime and the development environment is one thing.

If I wanted to, I could create pipelines and GitHub deployment workflows, but why would I want to? I'd much rather simply click the save button and such save some 60 minutes of work by saving straight to production, and test the thing immediately afterwards from within the same environment I created the thing.

My platform is merging the runtime environment, the development environment, and the testing environment, into a single piece of software. You can find more information about Magic Cloud here. In addition to the above advantages, my platform has also reduced the number of files required to deliver a feature from 50 to 1. In C# I'd need a handful of unit test files, a couple of extensions to map up my services, some 3 to 4 interfaces, and a couple of service implementations. On top of this I'd need a couple of model files, some AutoMapper configuration files, a Data Repository implementation plus its associated interfaces, and God knows what more. Look carefully at the above file. It's about 25 lines of code in total, and it is all the code required to deliver the feature.

Conclusion

From my point of view our industry's so called "best practices" is literally madness! Our best practices is stuffed with rigid bureaucracy to an extent that would make a USSR commissaire blush. Our "best practices", that was created to make software development more "agile", is providing us with the exact opposite result.

To understand just how crazy our industry is, realise that when I saved straight to production in the above video, I decreased the cost of delivering that feature from $10,000 to $16. I spent 0.16% of the resources required to deliver a feature, and the end result is the same.

If you want to continue using "best practices", then it's a free world. By all means, continue using your "best practices". But don't come and complain to me when your client tells you he'd rather be working with me instead of your company, because I can deliver something to him 10,000 times faster and 625 times less expensive than you and your company.

I'll take your money and say thank you. Nothing personal, it's just business!