This post is a synthesis of two posts I originally published on my other blog "unRelated".
One of the key foundations and most attractive principle of Agile or Lean methodologies is that "Everyone can help each other remain focused on the highest possible business value per unit of time".
I am certainly a strong supporter of that principle. However, value is often difficult to assess, I would actually argue that it is easier to identify what has less or little value, but what we think as valuable can potentially lead to many false positive, or simply be "business-as-usual" and hide the broader structure of the solution.
"User Stories" are the corner stone of identifying and delivering value:
An argument can be made that the user story is the most important artifact in agile development, because it is the container that primarily carries the value stream to the user, and agile development is all about rapid value delivery.
In practice, very few people focus on the benefits part of a user story. All user stories I see are either what we used to call "requirements" (just phrased slightly differently but isomorphically) or "tasks" needed to advance the state of the project.
However, there is a fundamental flaw in the construction of user stories, even when they are properly written, because they somehow make an assumption about the shape of the solution, and drive the author to turn almost immediately in solution mode, leaving no room for creative and out-of-the-box thinking.
Let's compare the metamodel of a User Story and to the formal definition of a Problem. The metamodel of a User Story looks like that (using the BOLT notation):
As a <role> I want to <action> so that <benefit>
I define a problem formally as a non existing transition between two known states [1], the metamodel of a problem looks like that:
A solution is a way to transition between these two states. Please note that both the actors and the actions are part of the solution:
This is where the problem lies when using User Stories, you are specifying the requirements with the solution in mind. There is, of course, a general relationship between some of the actors and entities of the system with the "start" and "end" states of the problem. The problem states are always defined in terms of their respective states (possibly as a composite state), but it is a mistake to think that the actors and entities that perform the actions, as part of the solution, are always the same as the actors and entities related to the (problem) states.
Hence, an action is solution centric and should not be part of the problem definition. As soon as you pick one, you have put a stake in the ground towards the direction you are going to take to solve the underlying problem. The other issue is that the start and end states are never clearly identified in a user story leading to confusion in the in the solutioning and verification process, since the problem is not defined with enough precision. Benefits could sometimes align with the target/desirable state, but the definition is often too fluffy and more goal centric, not effectively representing that (problem) state.
Ultimately, the relationship between problems and solutions is a graph (states, transitions as problems, actions as solutions), and this is where the coupling between the problem space and the solution space at the User Story level becomes unfortunate. This means that User stories cannot be effectively nested and clearly cannot fit in hierarchical structures (which is common to most Agile tools I know). This problem is quite accute as teams struggle to connect business level user stories and system level or solution level user stories. The concept of having a single parent directly conflicts with the possibility of having multiple possible transitions into a single state and decomposition principles where the same problem appears in the decomposition of several higher level problems.
I feel that distinction is profound because we can now clearly articulate:
a) the problem statements with respect to each other (as a graph of states and transitions)
b) we can articulate the solution in relation to the problem statements
c) we can articulate the verification (BDD) in relation to the problem and solution [2]
d) we can actually articulate the Business Strategy [3], the Problem Statement, the Solution and the Verification with the same conceptual framework
e) derive the Organizational IQ from the problems being solved on an every day basis
To the best of my knowledge none of these articulations have been suggested before and no one has ever provided a unified framework that spans such a broad conceptual view from the Business Strategy to the Verification. In the proposed framework the business strategy is simply a higher level and specialized view of the problem and solution domains, but using the exact same semantics (which are described here). In other words the enterprise is a solution to a problem, which is a composition of smaller problems and more fine grained solutions, etc. This has an extremely important implication for the execution of the strategy because now both the Strategy and its Execution are perfectly aligned, at the semantic level: the strategy, problem, solution and verification graph represent a map that everyone in the organization can refer to.
To take advantage of this new conceptual framework. I suggest that we make a very simple and easy change to Agile and replace "user stories" by "problem statements". Each problem must be "solutioned", either by decomposing it into simpler problems or solutioning it directly. Value can still be used to prioritize which problems are addressed first, that part of the Agile and Lean movement is very valuable, so too speak, but the focus on problems and solutions opens a new flexibility in how we handle the long range aspects of the solution while enabling the highest level of creativity and ultimately a direct articulation with the IQ of the organization.
As problems are decomposed, we will eventually reach a point where the subproblems will be close to or isomorphically related to the solution. But it would be a mistake to not clearly delineate the problems from solutions, simply because at the lowest level, they appear isomorphic.
If we start drawing some BOLT diagrams, a problem lifecycle can be defined as:
The fact that the lifecycle is pretty much identical as the one of a user story enables most of the Agile processes and tools to work nearly unchanged.
You may want to know "How do I write a Problem Statement?". Personally, I don't like canned approaches. Oviously here, the mere definition of the two states (low value and high value) is enough to describe the problem. If a solution already exists (i.e. it is possible to transition between these two states) you may want to describe some characteristics of the new solution. I googled "How to write a Problem Statement?" and I felt there was already a good alignment betweent the results and the abstract definition provided above. For instance:
We want all of our software releases to go to production seamlessly, without defects, where everyone is aware and informed of the outcomes and status. (Vision)
Today we have too many release failures that result in too many rollback failures. If we ignore this problem; resources will need to increase to handle the cascading problems, and we may miss critical customer deadlines which could result in lost revenue, SLA penalties, lost business, and further damage to our quality reputation. (Issue Statement)
Here we see two states for the releases: initial state (low value) tested, and the high value state (in production). There is also an undesirable state (failure) that the new solution will prevent reaching. For me the most important thing is that the problem statement must avoid at all cost to refer to the solution. Even if the people specifying the problem statement have an idea about the solution, they should capture it separately.
This new focus on problem & solution provides a rich conceptual framework to effectively organize the work of a team. After all, we have been innovating, i.e. creating solutions to problems, for thousands of years, so it is no surprise that our vocabulary is quite rich. Here are a few concepts that could be used:
Goal: a goal is not a problem, but you often need to solve problems to reach goals, so it's important to keep them in mind
Fact: a fact often constrains the solution, so they need to be clearly surfaced and accounted for
Assumption: assumptions are very important because they also constrain the solution, but in a more flexible way. Assumptions can be changed, facts generally cannot.
Statement: the problem statement is what physically replaces the user story.
Hurdle: During the decomposition of a problem, hurdles might be identified, they are not a problem per say, but they impact the solution. It could be for instance that a resource is not available in time to meet the deadline.
Snag: A problem can be downgraded to a snag as the solution is obvious to the team and represent a low level of effort. It can also be a small unexpected issue, that need to be quickly resolved.
Dilemma: A problem can be upgraded to a dilemma, when several solutions are possible and it is not clear which one to chose
Setback: The team can suffer a setback when it thought it had found the solution but it didn't, or could not find a solution and need to reassess either the problem or the approach
On the solution side, we can also capture different elements and stages of the solutioning process:
Answer: Findings related to a question raised in the problem statement.
Result: A validation that the solution conforms to a Fact
Resolution: The choice made after reaching a dilemma
Fix: a temporary solution to a problem or a snag to make progress towards the solution to the greater problem
Development: An element of the solution, usually the solution to a subproblem or a snag
Breakthrough: The solution found after reaching a setback
Way out: A solution was not found, nevertheless, the project reached a satisfactory state to meet some or all of the initial goals
...
From a management perspective. The Solution or Delivery Manager can escape the bureaucracy that Agile has created. Ironically, moving stickers around is a zero value activity, with zero impact on the organizational IQ. The solution manager can and should be responsible for the IQ of the project, which rolls up and benefits from the IQ of the organization. It should keep track of the elements that are incorporated in the solution as problems are solved. It should encourage team members to be creative when necessary and to shamelessly adopt existing solutions when it makes sense. It should help resolve dilemmas and push for breakthroughs.
The PMO organization becomes the steward of the Organization's IQ.
As we define problems and solutions in terms of entities, state, transitions and actions, the BOLT methodology provides a unified conceptual framework that spans from Business Strategy to Problem and Solution Domains to Verification (BDD).
To summarize,
1) We have provided a formal model of a problem and a solution, and how they relate to each other
2) This formal model offers the ability to compose problems and solutions at any scale, over the scope of the enterprise
3) Problems and Solutions can be composed from Business Strategy down to Verification
4) We suggest that Agile methodologies replace User Stories by Problem Statements
5) With the renewed focus on "problems", we can also integrate the work of Prof. Knott on Organizational IQ in the whole framework
Last, but not least, decoupling problem definition and solution yields a tremendous benefit in the sense that both can evolve independently during the construction process.
_______________________________________________________________________________
[1] For instance, you build a vehicle, obviously you want to car to transition to the "in motion" state. Different "actions" will lead to the vehicle to reach that state (a horse pulling, an engine, transmission and wheels, a fan, ...).
[2] BDD Metamodel (Scenario):
[3] Living Social Business Strategy mapped using the same conceptual framework (Source: B = mc2)
Data services are often an essential part of mobile solutions. It can be pretty tedious to manage a data access layer (say written in PHP) and a database schema (say MySQL).
Over the past few months, we have built a number of prototypes and a fairly large scale project that is about to go in production using MongoDB hosted by MongoLab.
What we noticed is that all we had to do was to create a collection for each entity and everything else would happen in mdsl. I must admit this was a nice side effect of mdsl, not necessarily something that I had designed for, I was simply exploring what you could do with MongoDB. Of course, this works well for CRUD operations since there is no data access layer per se, but still, it seems to fit lots of mobile solutions like a glove. The freedom of not having a rigid schema and the ability to add attributes and rows by hand as needed makes a big difference when you are building a solution: all the boiler plate code that keeps the client, data access layer and schema goes away. I cannot emphasize enough how easy and fast developing a connected a mobile solution becomes.
Here is a typical mdsl connection definition to a MongoDB database:
The first operation fetches the entire collection of patients (of course not very realistic). The createPatient operation POSTs a new patient to the patients’s collection. The JSON body is constructed automatically by the generated code within a “row” element as shown on the right.
Canappi’s knows readily how to create, read, update or delete these types of record.
The third operation, getPatientByEmail, implements a very simple query, using MongoDB query language and assuming the row element name is “row”. Here is what the resulting json document looks like in MongoDB, using the MongoLab console:
Here is how a join between two collections can be defined, assuming an event has a foreign key, itemid that points to an item detail document:
That's it !
03/10/12
Mobile Diet
No, I am not going to leave my iPhone or iPad alone for some months or scale down on using them. I am really talking about food diets. A completely different topic. As most people probably guessed by now, I am a gadget junky. I don't buy big toys (like cars), but occasionally, I like to have the latest gadget, just because it's cool. So I invested last June in a Withings scale. This is a beautiful equipment, easy to set up and completely seamless to operate for the whole family. You step on the scale and it wirelessly sends you data to their server. You can diplay graphs and data on your favorite mobile phone or tablet.
Last November I reached 240 pounds (109 Kg). I never weighted as much before and when I saw the video of a talk I gave at l'Ecole des Mines de Nantes, I felt it was time to do something. But What ? yes eat less / better, exercise, ...
I have lost lots of weight twice in my life: by exercising for a whole summer and after I got maried when my wife cooked specials low cal meals. Today with two kids, jobs, and other stuff going on, we tried, but neither were really an option. Sure there are millions of diets out there and nothing I could do really worked.
I even bought a fitbit to understand how much more I would have to exercise. I would not recommend anyone buying this device, this is the most expensive useless gadget I ever bought ($99). It is basically a glorified pedometer and nothing more.
So since the end of November, in about 3 months, I lost 22 pounds (10 kg), but what's most important is that the withings scale taught me how to eat and ultimately how to control my weight. So basically I dropped calories from my meals until my weight started going south. I lost all this weight without going to the gym or starving. As you can see in the graph below, when I got the scale in June, I somehow eat a bit less, but my weight crawled up until November without really understanding why. I was fighting it, but without much success.
So here is my diet (I am sure you can find yours):
- I eat the same thing at Breakfast and Lunch everyday:
- An 8 grain roll and a coffee at Starbucks and a Honey Oat Veggy sandwich at Subway.
- When I get home around five I eat a fruit or a yogurt.
- I eat whatever on the table (but small portions) with the family in the evening.
- If I can also do a veggy sandwich in the evening I do it (in case we are out running errands).
- Weigh yourself everyday, my weight curve was a huge motivator
- Walk a bit more here and there
I never felt hungry the whole time.
That's it, nothing else, nothing more. No need to buy a book or tapes, cook special meals, kill yourself at the gym, weight anything. Each time I did a "real meal" you can see a step in the curve. This is when we had friends at home or we went out.
Yes, and my blood pressure went down too. I am still heavy (99 Kg) so I expected it will drop more on my way to 80 Kg.
So what I learned?
- Eating out is bad, really bad for your health. We used to eat out at least twice a week, not to mention lunch. I am sorry to say that to the millions of restaurant and fast food owner, but what is convenient and fun is basically a silent killer.
- SCHOOLS MUST ABSOLUTELY OFFER A LOW CAL ALTERNATIVE TO BREAKFAST AND LUNCH
- It is amazing to see how few resources the human body can use to run all day
- I can't imagine how much food is wasted each day for absolutely no reason
- Salt does bring your blood pressure up
- I know today how to control my weight for life. This is priceless.
Yes, my energy levels are very high, I feel really good and every morning I can't "weight" to jump on the scale.
I hope you'll find that helpful.
Just in case you wonder, I am the biggest loser in the family and I am trying to convince my kids and wife to do the same thing.
Subbu wrote a post earlier this month on the Architect role, here he goes:
- You always talk about the big picture.
- You think you know how the system ought to be built.
- You are unhappy that the team is not executing your ideas the way you want them.
- You don’t have a working build.
- You spend a lot of time on documents that are not code.
- You can prototype – but your code is not production worthy.
- You spend too much time in meetings.
- The best code you wrote is a few years old.
- When asked for opinions you tend to speak in general terms.
- Your team members secretly joke about you.
- You start to take analysts and tech blogs too seriously.
- You are a dinosaur.
It's hard to disagree, though I find the list widely incomplete, specially when it comes to "everyone but your mum has an opinion on what the architecture should be", "vendors tell your boss you suck at archicture (unless you buy their product)"...
I am a bit more at odds with his conclusion: Code. Don’t wiki. Don’t powerpoint.
To code or not to code, that seems to be the question: in our industry these days, you code, therefore you are.
Just take any interview with Microsoft, Amazon, Facebook, Google ... and you'll face insipid Comp Sci 101 questions such as: how do you compare two binary trees? So, you bring 25 years of experience and passion, and the best and first thing these companies can do is to have a 25 year old kid ask you to write 5 lines of code. Everything else you have done is irrelevant. That is Subbu's world.
Allow me to take a real example to illustrate how a "coder" architects. A few years ago I was invited at Microsoft for a pubic event, and in a rare insight, a Microsoft architect was proudly explaining why Windows 2003 (R1 if I recall correctly) did not scale as a web server? The developer in charge of the connection manager had used a ... linked list to manage the connections. I bet this guy had brilliantly passed all the interview CS 101 questions ... Shall we also speak about the kids at Facebook who code your privacy away? Isn't a primary key a convenient way to fetch your favorite piece of information?
The reality, is that Subbu makes the deeply and totally erroneous assumption that we have reached a level of maturity that gives us the perfect communication tools and hence with that in mind of course, writing code shall be the answer.
If you think that a) communicating, b) how and c) when you communicate is irrelevant, I would strongly suggest you watch this presentation from start to finish. Don't get me wrong, coding is great, I love coding, specially metaprogramming, but the question still remains, is an architect, JUST-A developer, hence Archaic, or is his or her role more essential (as in essence), i.e an Archetype ?
Why not think out of the box slide for once? beyond the trees, and the queues, the arrays and the lists, the maps and the sets? Why not ask how Model Driven Engineering could shape the role of an architect and establish a strong and precise articulation between architecture and coding? and with it, enable architecture refactoring ...
Let's review Subbu's list in the light of MDE:
| You always talk about the big picture | In MDE, you talk about the Solution Model with the highest degree of precision possible. There is no "big" picture, there is an objective, traceable representation of the blueprint of what you are building. |
| You think you know how the system ought to be built | You don't know, with MDE you rapidly try different technical architectures and enable architecture refactoring, just in case. |
| You are unhappy that the team is not executing your ideas the way you want them | A solution model can go a very long way in bringing people on the same page and eventually, the quicker you get on the same page, the faster you execute. Heck, you can even implement part of the solution model yourself. |
| You don’t have a working build | With MDE, the build starts with the solution model |
| You spend a lot of time on documents that are not code | With MDE, you spend all your time having a meaningful impact on the code. |
| You can prototype – but your code is not production worthy | Your solution model is production worthy and drives the code of your team. |
| You spend too much time in meetings | you don't have to spend much time in meetings. With a clear solution model, you facilitate meetings and rapidly drive to the right conclusion be it technical or functional. How many people "scrumly" hash and rehash the same arguments for weeks, months and eventually request to build something that is not what they had in mind while cutting the scope to the bone, just to claim they shipped something? Who doesn't want more precision in meetings? Are PPTs or Wikis bringing that precision? Is code bringing that precision? |
| The best code you wrote is a few years old | Your best models are still ahead, you love what you do and you can't have enough of 24 hours per day. |
| When asked for opinions you tend to speak in general terms | when asked your opinion, you can articulate your ideas and the ones of others with the highest degree of precision, creating a clear understanding of their architectural impact and the corresponding level of effort. |
| Your team members secretly joke about you | you feel part of the team and you communicate effectively your ideas. The code developers write is 10x more interesting to write. |
| You start to take analysts and tech blogs too seriously | Analysts and tech bloggers have not idea what MDE is, by the time they catch up, you'll be retired. |
| You are a dinosaur | yeah right ... |
Shall I also mention that the ultimate beauty of MDE is "No Middleware"?
So, for a RESTafarian, who recently admitted:
Hypertext made a lot of sense when I was looking from the server. A few months spent writing real-world client code changed all that.
I am not really sure that Subbu is in the position to teach us some lessons about what to do, or not to do. Very few "Coders" seek to understand the context in which they code, or poke up to the solution model, and I am not even talking about the problem model. So yes I am disappointed, but not surprised to see someone the caliber of Subbu, thinking that we have to return to the early sources (so to speak) of software engineering. The RESTafarians have already thrown us back 15 years, what's another 15 years on top of that?
It's time to let the Architect surface the Arche (In ancient Greek Philosophy, Aristotle foregrounded the meaning of arche as the element or principle of a thing, which although undemonstrable and intangible in itself, provides the conditions of the possibility of that thing.)
I must admit, MDE is a joy to work with, especially as an architect. MDE allows you to express how a certain class of solutions should be built, far away from the intricacies of general purpose languages, conventional type systems and SDKs. It allows you to solve problems, in ways that simply would never have any room in a GPL world. I may never know if MDE would have changed the face of software engineering, but for an industry that has looked for the holy grail of programming languages for so long, a paradigm shift seems innevitable. If for nothing else, all our software development technologies and processes have been aligned along a "monolithic" assumption, when today solutions are composite and often requires several architecture variants to support to different use cases.
Let me take 3 examples from the Canappi 1.2 release. to show where and how MDE makes a powerful difference.
1) MDE enables solution architecture variants : one of the key features of 1.2 is an enhanced level of support for Universal Binary iPad/iPhone applications. You can now define device specific layouts which will be displayed when the application runs on that type of device. The kitchensink demo has been updated to take advantage of that feature. Here Canappi uses tablet variants, but it would be just as easy to add it for different orientations.
layout sessionDetailLayout_iPad {
// iPad specific layout
}
layout sessionDetailLayout {
text sessionId '' (-20,-20, 10,20) //hidden parameter
text sessionTitle '' (7, 45, 305, 65) { Left ; }
text sessionPresenter '' (7, 110,290, 20) { Left ; }
tablet sessionDetailLayout_iPad ;
}
There is simply no other mechanism that allows you to do that so elegantly because you are constrained by the underlying architecture of the SDK you are building your solution onto. When you look at Apple and Android SDKs, you can clearly see that the support for different form factors simultaneously is an "after-thought", not a key architectural foundation.
Furthermore, any architectural deviation from a given SDK translates into lots of boiler plate code, scattered across the entire solution's code base. MDE completely hides this boiler plate code from the solution model.
2) MDE enables the creation/addition of new logic semantics. Mobile apps often need to call more than one API to get the data you need to populate a user interface. For instance, when you need to display the thumbnails of a Flickr gallery, you would think Yahoo's Web API GET /gallery/{id} would return all you need? wrong, it only returns some gallery information with just the photo ids, you need then to make a second call for each photo_id to get the thumbnail URLs to download the thumbnail image files.
So in this case, not only do you need a solution architecture variant (call 2-N APIs given a call to a single API), but you also need to express the logic of that call. No mystery here, that kind of logic is probably a few thousand of years old, and in modern day computing, this is simply called a join:
connection flickr {
operation init getPhotos GET 'http://api.flickr.com/services/rest/?method=flickr.galleries.getPhotos&api_key=API_KEY&format=rest&gallery_id=GALLERY_ID' {
resultSet 'photos' ;
join getSizes on photo_id = id where _label = 'Square';
}
operation getSizes GET 'http://api.flickr.com/services/rest/?method=flickr.photos.getSizes&api_key=API_KEY&format=rest' photo_id {
resultSet 'sizes' ;
}
}
Yes, it's that simple ! With just a bit of code written once for Flickr and abstracted a tiny bit, I can implement most mashups.
But that's not all, a "side effect" of MDE, in this case, is the ability to refactor your architecture. I happen to believe that mashups should mostly run on the client, unless there are some reason not to bring the data on the client (e.g. the end user is not allowed to see part of the data, bandwidth constraints...), but this point is irrelevant, there will always be the need to do some mashup both on the server or the client. Subbu's team has come up with a nice way to do that on the server side, ql.io.
So how would I enable such a massive architecture refactoring? a simple keyword and a tiny bit of code in the code generator (that generates ql.io scripts and some code on the client that invokes the mashup). I'll try to illustrate that for the next release.
join getSizes on photo_id = id where _label = 'Square' with qlio ;
3) MDE enables you to create solution oriented type systems. Many would argue that the main purpose of a computer is not to "compute", but to manage state persistently. One essential aspect of managing state is data structures and the building blocks of data structures are described by a type system.
One of the challenges when building apps and mobile apps in general is that the UI is quite varied. Take the example of a Map for instance, it often comes with points of interest. How do you bind a data set to a Map such that it displays push pins? just like you want to display rows of values in a table or pictures and picture information in a gallery?
In the case of Canappi we built a simple binding framework that lets you express that the result set from a Web API call is bound to a "layout" (a set of controls). You can optionally use a fromKey / toKey mapping when the attribute names of the result set are different from the names of the control.
layout myMap bindings pointOfInterest with mapping aSimpleDataMapping ;
In this statement,pointOfInterest points to one (or more) APIs that gather the data that is automatically bound to the map control which supports binding to a single push pin (lat, long, title and subtitle) or an array of pushpins. The reason why we make it that simple, is because we took the decision early to normalize the response before we bind it to the UI, i.e. we built an implicit type to which Web API response formats map to, on one end, and from which UI views (with any control) bind to.
Ok, I understand this is quite basic, but incredibly productive for at least 95% of the data that moves from a server to a client and back: I don't know any programming language that allows this type of consision (e.g. a twitter app in 30 lines of code). Yet, hundreds of thousands of developers, every day, write some code that picks up some data from some kind of back-end API call and puts it in some kind of UI element.
These examples are the bread and butter of MDE, they are very easy to implement and I would argue that they add less than 20-30% overhead to your first implementation of a variant, type of business logic or data binding. That means on your second implementation you already gained overall 20-30% of your time. So next time you look at the architecture of your solution why not ask these questions:
a) Is there any variant in your solution architecture?
b) Does your architecture deviates from the architecture of the underlying SDK / Platfrom on which it is built?
c) Are you using some business logic that is not easy to express with the programming language that you are using?
d) Would you benefit from extending the type system of your underlying programming model?
If you answer yes, to one or more of these questions, I would certainly take a good look at MDE.
02/02/12
Is HTML 5 losing mindshare?
The new Path? The one that won a Crunchie last night for great design? It’s not done in HTML 5.
This morning I saw something new coming soon from Storify. Not done in HTML 5. This morning I visited Foodspotting which just shipped hot new apps on iOS, Android, and Blackberry. Not done in HTML 5.
More and more I’m hearing that designers and developers are ignoring HTML 5, especially for the high end of apps.
After building Canappi, I can only wholeheartedly agree with Bob. HTML5 has certainly a place in the mobile landscape, if for nothing else to "mobilize" your web site, but when it comes to user experience, we don't see how it can compete with Native Frameworks at least in the years to come: For every successful mobile web app, someone will build a superior native experience that users will adopt. There is simply no room to compete.
I am currently building Canappi's jQuery Mobile code generator and from what I can tell, it is extremely limited compared to the native iOS and Android SDKs.
The fundamental reason for Web Apps to emerge in the late 90s and 2000s was the "client update" problem and to a lesser degree the number of platforms on which the app should run. In the 90s, assistants used to roam the buildings with CD-ROM (and Floppy disks) to update every single client.
Today, App Stores have completely solved the update client problem (for mobile and desktop apps), and running on multiple platforms really means running on iOS and Android (although the fragmentation of Android is a bit of a concern).
Web Apps have many fundamental flaws, from flowing layouts which simply don't work in small form factors, to cluncky off line experience, not to mention bandwidth and power consumption.
If you combine a horrible developer experience to a horrible user experience, (Mobile) Web Apps have simply no room to grow from here.
