How dem dey develop software, dem normally dey aim to make sure wetin dem write down (specifications) match wetin dem build (implementation).
Because of dis, dem dey design systems to fit wetin dem specify, and then dem go build am based on those designs. After that, dem go test am to confirm say di thing wey dem build match di specifications; if e no match, dem go correct di thing wey dem build, and if di specifications no clear, dem go make am clear.
Dem fit call dis one Specification and Implementation-Based Engineering.
But for today, when dem dey talk about software, dem dey focus more on user experience.
And e be like say, na di way di software dey behave, no be just how dem build am, na im dey really shape di user experience.
So, outside di framework of specification and implementation, experience and behavior dey exist.
Because of this, I believe say e worth am to explore di idea of Experience & Behavior Engineering, wey dey based on experience and behavior.
Liquidware
Experience & Behavior Engineering na way wey no really fit for traditional software development methods.
Dis na because e dey require say dem go improve wetin di user dey feel without hard boundaries or clear division of functions for di specifications. E fit even be say one simple request from a user to make di experience better go mean say dem go need to throw away all di software wey dem don develop before.
But for one time where agent-based software development automation by generative AI don common, rebuilding di whole software systems go dey acceptable.
Wetin pass dat, for such a time, e dey possible say we go enter di age of Liquidware, where developers go release software wey get AI engineer chatbot, wey go allow users to change di UI to fit wetin dem like.
Liquidware mean software wey flexible pass normal software, wey fit each user perfectly.
With dis time of automated development and Liquidware, di engineering way of specification and implementation go old.
Instead, we go change to di way of Experience & Behavior Engineering.
Wetin be Behavior?
To make am simple, behavior na state wey dey change as time dey go.
And to test behavior na to test dis state wey dey change with time, no be any other thing.
Wetin pass dat, testing behavior no be to confirm say e match wetin dem write down for specifications wey define how states dey change. Instead, dem dey test behavior by how good de user experience be.
Of course, if bugs dey wey make de system do wetin de user or developer no expect, dis one go really spoil de user experience. So, testing behavior also include checkin' if de functions dey correct and valid.
So, after dem don fulfill these basic functional requirements, dem go test behavior to see how high de quality be from de user experience side.
De Ultimate Experience
For human beings, de best user experience na how dem dey control their body when dem dey healthy.
Just imagine: everyday, we dey control our body wey weigh plenty kilograms—na one complex system wey get plenty limitations and restrictions—to do things wey get purpose.
If we try to control such a heavy, complex, and restricted system to do wetin we want, de experience go normally be very bad.
But, as long as we no sick, we dey move dis heavy, complex, and restricted body as if e no get weight at all. We dey operate am without thinking twice, as if e be one very simple machine, and we barely notice its limitations or restrictions, as if dem no even dey there.
Dis na de ultimate experience.
By chasing after high-quality behavior, e possible to provide an experience wey dey as good as controlling your own body.
In other words, even if a system dey slow to process, get complex functions, and get plenty limitations and restrictions, e fit become Liquidware wey no dey give any stress at all.
Konklushon
De ultimate Liquidware go give experience wey be like our own body.
Such Liquidware go become, for us, like part of our physical body.
Every time de ultimate Liquidware dey plenty or dem make am better, e go feel like our body dey expand.