Where programming was 35 years ago (for me)
When I first started programming in the early 80s, using BASIC, we often had “spaghetti code“.
The whole program was in one file. Every line had a line number. Instead of creating objects, you set variables – usually global variables. Instead of calling methods, there were GOTOs all over the place.
These programs were difficult to write, difficult to read, and difficult to maintain.
“Structured programming” came along, and added some order to this. But it was still far too easy to write programs that were difficult to maintain.
Object-Oriented Programming to the rescue!
Then, Object-Oriented Programming (OOP) came along.
Now, instead of having a bunch of global variables, you have objects that you pass around. Instead of running a small piece of code by using a GOSUB, you call a method on the object.
OOP is easier to work with and understand, mostly (to me) because it puts smaller pieces of code in more obvious places.
However, most of the OOP programs I see in the “Real World” seem to just be structured, sequential code, in a nicer wrapping.
Most classes, properties, and methods are public. Workflows are still handled synchronously, with sequential calls from one method to the next.
Agile to the rescue!
Next, to improve development, and code quality, we got “Agile”.
Many of the Agile practices come from manufacturing principles, such as Just-in-time and Lean manufacturing.
Delivering in frequent, short iterations is the software development way of having smaller batch sizes and delivering smaller pieces of value – faster. Continuous integration (and running tests during the integration) is roughly the same as moving QA to earlier points on a factory line, to prevent problems further along in the process. Storyboards are Kanban boards. We [sometimes] do retrospectives and use “The Five Whys” to get to root problems.
But there are still missing parts
We’ve made improvements with Agile, but there is still much more to do.
One of the practices of the Toyota Production System (the most well-known implementation of Lean-ish principles) is “Poka-yoke” – mistake-proofing. Instead of making it so we can quickly and easily detect errors, find a way to prevent the error from ever happening.
What about improving the processes inside the program?
If Lean/Agile is a great way to handle the process of writing programs, what if we applied the same principles to what is happening inside of the programs?
After all, a program is only a process of moving data through pre-defined steps. The same as an assembly line making widgets, but without any of the messy physical stuff.
I’m going to think of the data moving through an assembly line (something I’ve been doing for a while). And I’ll see how I can apply the principles from Lean Manufacturing to my data factory’s assembly line.
Building a web app, using these ideas
I’m sure some of the Erlang, and MMORPG, programmers see this as their regular way to work. However, I’ve never seen this implemented in any of the corporate settings where I’ve worked.
So, I’m going to try this out, and see if I can come up with a better way for me to build my applications. Worst-case scenario, I at least learn a few new things.
I don’t know exactly what I’m going to have this sample app do. It will probably be based on some of the intranet applications I’ve built in the past – ones that needed different departments to perform different actions on whatever form/order/request was submitted.
I’ll try to make it generic enough that I can re-use for future clients.
Basic principles
One of the most important principles I need to keep in mind is avoiding the “Not Invented Here Syndrome” – where I decide it’s better to build something from scratch, instead of spending a little time finding (and learning how to use) existing frameworks and libraries.
I’ve seen that happen far too many times in the past.
In fact, I saw one company declare that SQL Server was “too slow”, so they were going to write their own in-memory data manager (sigh). The reality is that they were just doing some horribly inefficient things with SQL Server. But, no one wanted to admit that.
Changes to my programming style for this experiment
I don’t know how this will work out, but these are some of the things I’m going to try first:
- Scope is as restricted as possible
- Public classes and methods should effectively be APIs
- All properties use private setters
- All properties must be bindable to the UI
- All objects are instantiated from factory classes
- All classes implement an IsDirty property
- If value is ‘changed’ to the same value, it is not dirty
- All (?) communication from the objects, back to the UI, is done by raising events
- All methods must be void (?)
- Actions performed to objects are managed by rules-based state machine
- No sequentially calling a chain of methods
- Data (active business objects) is held in a pool
- Able to be used by other parts of the program (Workers)
- Workers are managed separately and can be spun up on demand
- Run in their own threads
- App can spin up new ones, if performance slows down
- Data updater (for IsDirty objects)
- Alerts when objects stay in a state for too long
Leave a Comment