On Building Software
This is a snapshot of a whiteboard that drew by software team in one of my previous jobs. It was a team building afternoon, and we were playing a game similar to Pictionary - each person have to drawing with clues about the word they had received for others to guess. When it was my turn to give the words, I decided to pick only one word for the entire team. As you can see, very different pictures were the resulting from the same word! Can you guess what this word was? Please t
ake a minute for a close look.
Smoke came out from the ears? Rollercoaster rides? A ball of mess? Staring at a monitor seeing tangled threads? Waterfall? Is this word FRUSTRATION or CONFUSION or CHAOTIC or AMBIGUOUS or SETBACKS or FATIGUE?.
This word is SOFTWARE! Sadly, this grim picture truly reflects some key aspects of software development in many organizations, where software developers experiment frustration and confusion and chaotic and ambiguous and setbacks and fatigue.
Modulation, encapsulation, and API standardization … with each technique or method added to our toolbox, we hope software construction would be like building LEGOs - finally plugging all pieces together, and HURRAH, it works. But our experience revealed to us again and again, that building software is more like solving a Rubik’s cube, often after we put one cube in the right spot, by accident we moved another one to the wrong spot.
“The first 90 percent of the code accounts for the first 90 percent of the Development time. The Remaining 10 percent of the code accounts for the other 90 percent of the development time. ”
When I first started learning computer science, my parents who were teaching mechanical engineering at a college in Beijing, often asked me, can you tell us what computer software is? And they would hand me a pencil and asked me to draw. I often told them with arrogant that software is abstract, there is no way I can draw. They then shook their heads with disbelief, since in mechanical engineering, drawing is everything - they give an exact representation of the object and show all parts in their true size relation. Mechanical drawing is used to communicate design ideas, to eliminate uncertainties, and to validate the integrity of the design. Many years have passed since but the idea of drawing the abstract concept of software has been lingering above me - can we visualize the abstract concepts for the same purpose? That started my journey of discovering and using Hierarchical statemachine to “draw software”.
In the following slides, I use a buggy sample code from Microsoft as an example, to demonstrate how software can be or modeled in a systematic manner with "“drawings”. How to use the modeling (drawing) method to capture the complicated real world frequently changed requirement, and how to use the model to reduce the design complexity, while maintain the system as whole, communicate the design to implementation, and finally to validate the design and to verify its implementation. This will not only eliminate “the other 90 percent” of work, but also bring the software quality to the next level. It is not only works correctly, but also has better user flow.
My goal here is to shad light on systematic design in software development. I truly believe it is the direction to go to solve the current frustrations. I hope you will take this concept to heart and develop it further.
Opposite from a fairytale, each software project has a happy beginning, but rarely a happy ending.
At the beginning, everyone in the team are charged for a new project with enthusiastic and energy; The project idea is cool, the technology is new, and the teammates are super smart. But as it closer to the deadline, all the problems, aka bugs, are jumping out to push the deadline again and again. I’ve been seeing this happening everywhere, projects large or small, in companies large or small.
Since when the infamous 90-90 rule rules the making of complex software development?
Often it is someone else’s problem, right?
Maybe not…
Let’s try to root cause a problem.
I picked Microsoft calculator sample code because it is small enough for a quick understanding, but complex enough to demonstrate the problem.
This is a Microsoft sample code for Windows calculator.
While it demonstrated the strength of the software development tool, it exposed a problem of software making in even in the famous software house.
It crashes a lot.
Ian Horrock, a computer science professor, said, in an hour with different scenarios, he could make it crash, or freeze for more than 10 times. It normally works well, but only when you try to enter something out side of the rules for a calculator input, For example, punch in “2 + + 3”, or “ x 2 + 2, or 2 + + 2 will crash it.
Just fix the bugs!
You may say, it’s normal for software to have bugs, just fix the bugs, it will be fine. But what if you fix one bug, on the next round of testing, 2 more bugs were found, which was caused by your bug fix. Repeating the fix-test cycle, that is where the other 90% Mr. Cargill mentioned.
The difficulty with event driven system
The challenge is rooted from, any even can come in any time in any sequence, but how to handle the event is based on the context. For example in the calculator, when you type 2 + - 3, it is totally fine. But if you type 2 + x 3, although both follows “operand, operator, operator, operand” sequence. But how can you distinguish it so the system would not process the second one?
The button-up design and the use of flags
A conventional way of “remembering” the context is to share flags between the event handlers, to set it, or to read it on a conditional statement. Each time we discover a missing context in our logic flow, we add another flag. Along with the growing number of flags, we started to trapped in a maze created by ourselves.
“When complexity also works, why bother with simplicity.” - Anonymous
This is a design document from Microsoft. On the good side, it actually has a document! But on the flip side, who has the courage to trace its logic, to maintain this documentation, and can still say it is correct with confidence? If you want to make a change here, how can you guarantee that you will not break something else? In other words, bottom-up design made us loose the sight of the system working together as a whole.
I’m wonder what is Weinberg’s fist law.
A systematic design for mechanical engineering, for building architecture, is modeling.
The born of Statechart
David Harel, a young professor at the time, mentioned that when he was invited to join a regular discussion on building a new aircraft for the Israel air force, everyone there was the top expert in their field. But the discussion often goes on and on with little progress, because there is nothing to help them to capture their thoughts, to organize them into a system, and to communicate them through different disciplines. He tried to draw finite state-machine like charts on the board to capture the ideas in a way so everyone can see it. That was eventually how the state chart was developed.
The control part in a Model-View-Controller as a system
It is an over used design pattern, the idea is to decouple the software into three parts, View manages the user experience, Model maintains the data collected or generated, the Control tracks the business logic and based on the context to notify View or Model. In this discussion, we focus on the Controller part.
The calculator Controller in statechart
Statechart maintains a context without the flagship flags.
Statechart support simplicity through abstraction, which concept has been used in Object—oriented design for several decades, that is using inheritance for a behavior shared among many components.
Abstraction is the key of simplicity. For testing, it means a huge deduction of testing coverage: instead of testing many times in each components, it only test once in super-class.
Statechar support a top-down design, which made it possible to see the system as a whole
The statechart modeling of a advanced calculator
What a relief!
For the semantics of the statechart, this specific character that to be able to map between the design and the implementation, is as important at mapping a mechanical drawing to an object.
A new way of event handling
Build on top of a framework for statechart
A generic architecture for a large but decoupled system
A real world class-III medical device built on statechart.
My favorite quote from this famous writer, the same principle applies to software writing.
If work makes you unhappy, either, it is not the right thing to do, or, we haven’t done it right.
—Jingyu Li 😀
Let’s do it in the right way!
Slides Show
The following is the slide show that repeats the content above. Click on the image to proceed.
