Erik on Software

Media Query Source: Part 38 InformationWeek (US digital magazine)Low code development platformsShort-term benefits for the non-technicalApplication lifespan often underestimated

---

My responses ended up being included in an article at InformationWeek (May 10, 2022). Extent of verbatim quote highlighted in orange, paraphrased quote highlighted in gray. Above image from cited article.

---

The query responses I provided to a media outlet on March 29, 2022:

Media: The good and the bad about low code.

Media: Looking for experts to explain the good, bad and the ugly about anything related to using low code development platforms. Let's make this article real-world, folks!

Gfesser: As a rule of thumb, firms likely can realistically expect some of the better low code development platforms to get them 80% of the way in terms of what they're looking to do, but it's the remaining 20% where the challenges reside. In other words, while it might be accurate to say that much of what a firm is looking to build in the near-term will be enabled by one of the better platforms, it's also likely that considerably less than 100% of mid- to long-term needs will be enabled.

From my experience, custom code will need to be eventually developed due to a variety of factors, such as unsupported features, unhandled edge cases, limited integration or limited scaling. Several years ago, for example, a health insurer CIO who had initially brought me on board as an enterprise architect for a digital transformation effort (the chief architect of whom later requested that I take over a portion of this effort following the director of architecture's departure), was sold on implementing one of the most popular low-code development platforms before the effort even started, and it didn't take long for issues to materialize.

Their presumption was that this particular platform would provide a significant jump-start with respect to building the user interface. And while this ended up being a generally accurate presumption, what wasn't taken into account was everything else that needed to be developed for the application. Quite simply, the chosen low-code development platform was built in a way which presumed use of its own components for services on which the user interface would depend. Yes, an effort to work with the low-code vendor ensued, but the jump-start didn't get the firm very far. 

In order to tackle that 20%, development teams needed to work with the platform vendor because everything was proprietary, not based on open source libraries or frameworks. Eventually, the platform was enabled to integrate with all of the custom microservices we were building, providing some needed flexibility and scaling, but there was a high dependence on the vendor in order to make this happen. What this means is that the vendor needed to modify their product, building their own code. While the development teams did not need to write this code, the vendor did, and the code was closed source. In effect, my client was funding the effort to build the vendor platform!

And it's very important to understand that it's not just what needs to be built that needs to be taken into consideration when adopting a low-code development platform. Typically, this type of product provides no version control (or version control only using a proprietary tool, kept separate from a firm's centralized version control) providing the ability to understand how instructions for a given solution have changed over time. And skillsets for such platforms aren't transferable. I've seen what initially seem to be some clever scripting languages, but apart from the incompleteness these often provide is the available talent base. Why would a strong developer want to pick up hard skills that they would never be able to use again? 

Don't get me wrong. Low-code development platforms can provide some short-term benefits, perhaps for non-technical individuals to build solutions due to a lack of developers (after all, there is a derth of talent). And perhaps these might suffice for some internally facing needs. But when it comes time to build externally facing applications for competitive advantage, low-code development platforms largely fall short. At a minimum, firms need to recognize what they're likely getting into when looking to adopt such a platform so that they can also actively plan for the long-term. As it turns out, most applications simply have a longer lifespan than initially expected.

---

See all of my responses to media queries here.

New Book Review: "Hero on a Mission"

New book review for Hero on a MIssion: A Path to a Meaningful Life, by Donald Miller, HarperCollins Leadership, 2022:

Copy provided by Amazon.

Just after I had first started reading through this book, someone commented to me that they had also started reading another book, entitled "Man's Search for Meaning", by Victor Frankl. In response, I remarked on a coincidence: Frankl's book is not only cited throughout "Hero on a Mission", the author of this other book is actually cited at the outset within the introductory pages. While I had heard about Frankl's book, I had also never felt any interest in reading it, because I've not only already read numerous war-themed autobiographies, I've also heard spoken accounts directly from victims of the second world war and immediate post-war period from my own family members, who suffered extreme hardships.

However, upon hearing about Frank's book again, I took a closer look to determine whether I might want to read it as a personal follow-up to "Hero on a Mission", and came to the same conclusion. In my view, the differentiator between these two works is the practicality that Miller seeks to provide to readers. Frankl's account of his experiences is provided in the first part of his book, and a paper on logotherapy is provided in the second part, but at this point I'm not interested in hearing more war stories or theories about a particular life philosophy, and am instead interested in hearing what logotherapy, the therapy created by Frankl, might look like from a practical perspective as applied to one's life.

Miller doesn't explain logotherapy in his introduction, but explains Frankl's pragmatic, threefold formula to experience a life of meaning in the third chapter: (1) "take action creating a work or performing a deed, (2) experience something or encounter someone that you find captivating and that pulls you out of yourself, and (3) "have an optimistic attitude toward the inevitable: challenges and suffering you will experience in life." And later in this chapter, the author makes these three elements more relatable as he discusses the life plan he has been using for the last ten years, a plan that continues to evolve, and a plan without which he feels his personal story would "devolve in entropy and ultimately a narrative void. The existential vacuum."

(1) "Life invites us to be important and necessary. If we wake up each day and have a task to accomplish, especially a task in which other people are involved or without which other people might somehow suffer, we become necessary in the world. We sense we have a purpose (because we do). By requiring a work or a deed, I think Frankl was saying: Get yourself a great reason to wake up and get out of bed in the morning. If you do, it will help you avoid the existential vacuum."

(2) "We should acknowledge that we are not alone in this world and in fact the world and the stories unfolding upon it inspire awe. We all know the greatest experiences we have in life are dramatically enhanced if they are shared with others. According to Frankl, to experience meaning, we should get involved with a small group of people we love and who love us, or we should find something that invites our focus beyond ourselves to the beauty of the world around us. A lone walk through the forest is good for the soul just as a trip to a gallery can offer inspiration and a sense of mental expansion. The point is this: encounter something that pulls you out of yourself so that you world becomes larger."

(3) "While I've found each of the three elements of Frankl's formula helpful, it's this last one that helped me transform the most. Essentially, Frankl argued there was no negative event that could happen to us that could not be somehow redeemed. "Redeemed" is my word, not his, but I think it's fitting. By redeemed I mean that, as humans, we are able to take the most painful of tragedies and turn them into something meaningful. Frankl believed that while tragedies should be acknowledged and grieved, they can also produce something beneficial. This doesn't mean tragedies are good. Nobody wants or should have to experience a tragedy. It only means that from the ashes of our tragedies we can create something beautiful, and by creating something meaningful with our pain we begin the process of healing our wounds."

Just recently, I mentioned in my review of "Do Something for Nothing: Seeing Beneath the Surface of Homelessness, through the Simple Act of a Haircut", by Joshua Coombes, that one of the author's passages reminded me of Romans 5:3-5: "...we also glory in our sufferings, because we know that suffering produces perseverance; perseverance, character; and character, hope. And hope does not put us to shame...". Interestingly, these verses also correlate with the third part of Frankl's formula. The hardships my family has experienced have been extremely challenging, and in the midst of these experiences, seemingly unbearable. But what's this? Hardship is actually the first step in a sequence, if we permit the rest of this sequence to play out. 

The author's presentation is broken down into sixteen chapters across a story's three acts: (1) "how to create a life of meaning", (2) "create your life plan", and (3) "your life plan and daily planner." In the first act, the author discusses the four roles we play in life - the victim, the villain, the hero, and the guide - followed by a focus on the hero, who accepts their own agency, chooses a life of meaning, and knows what they want. In the second act, the author discusses the eulogy, short-term and long-term visions, and the daily planner, and in the third act lays out the templates for each of these tools.

One of the most impactful chapters for me is the fourteenth chapter. While the role of the guide is discussed earlier in the book, the focus up until this point is the role of the hero. "Life requires experts. We need people around us who know what they are doing and can save us from our own mistakes. In a way this book has been deceptive. It has taught you to become a hero on a mission even though the hero is not the most evolved role. The most aspirational role for any of us is the role of guide. So why spend so much time teaching people to live as heroes when the goal of life is to become the guide? The reason is, of course, that we cannot become guides unless we have lived as heroes on a mission."

The author later comments that "Victor Frankl's ideas do not ensure that life will go well for us. They simply ensure that we experience meaning whether or not life goes well. His theories, after all, were crystalized in a concentration camp. Mental, physical, and spiritual competence happens when we move into the challenges life offers us. Victims do not face these challenges because they cannot. Villains cause many of these challenges. Heroes walk into and through the challenges and are transformed in the process. Guides, then, teach heroes all they know about how to surmount the challenges. Guides teach us how to have courage because they have lived a life of courage themselves. The reason we want to live as heroes on a mission is, the more we do so, the sooner we will transform into guides."

Subsequently, Miller presents the four characteristics he believes are most critical to develop in order to help others: experience, wisdom, empathy, and sacrifice. I particularly appreciated his explanations of wisdom and sacrifice, perhaps because, while I personally feel as though I'm well on my way in all these areas, I also feel more developed in the other two areas. On wisdom, for example, the author comments that "we know a hero is going to have to gain strength in order to meet the villain as an equal. The hero will have to be strong and wise, and the only way to gain strength and wisdom is to fail and then succeed, over and over." While as a software developer and innovator the need for failure comes naturally for me in the workplace, I can't say the same for life in general.

In the closing paragraphs of the sixteenth chapter, as he wraps up his presentation, the author makes some especially profound statements. "Life can be very difficult, I know. There are tragedies all around us. There is darkness. But don't forget, there is also light. We get to participate in the making of that light. When the existential vacuum comes for you, and it will, remember there is a hope that is very real in the world. We can always make meaning." Interestingly, Frankl focuses on "meaning", and Miller periodically uses the term "purpose" somewhat interchangeably, but he clarifies his intent in the third chapter, something for readers to ponder: "meaning feels like purpose."

"When I experience meaning, my life feels as though it is playing an important role in an important story. I have never been able to prove that sense of purpose is justified, but it hardly matters. When I am experiencing meaning, it *feels* as though my life is a story that is interesting to myself and also good for the world." While I don't particularly care for this explanation, I also value Miller's further thoughts on the subject. "How many people sit in church pews hearing lectures about God only to return home and feel restless? And why? Perhaps it is because we do not experience meaning by studying meaning. Rather, we experience meaning by taking action. Even Jesus said *follow* Me rather than *figure Me out*. What if the experience of meaning requires action?"

Community Comment: Part 17

The comments I provided in reaction to a community discussion thread:
https://www.linkedin.com/feed/update/urn:li:activity:6907398637354369024?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6907398637354369024%2C6907414040805834754%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A6907398637354369024%2C6907643873842376704%29

Enterprise Agile Strategist at Cloud Content Management Firm: 

Q: How do I get accurate estimates?

A: Estimates are BY DEFINITION inaccurate.

Value Stream Architect at Financial Technology Service Provider: 

What level of accuracy are you asking for? What is your risk tolerance?
70% confidence?
80% ?
85% ?

Gfesser: So I would personally question a development team debating about confidence levels with only a 5% or 10% spread, because the choice between such fine-grained levels is arguably arbitrary, making the differences essentially meaningless. I tend to think categories of confidence are better to use than percentages, just like point estimates. For example, "low", "medium", and "high", keeping in mind that "medium" confidence doesn't really provide any value. Low confidence means novel development is being tackled, and this type of work can't be predicted. High confidence means either similar work has been performed in the past, or the work is straightforward and relatively easy. The bottom line is that once sizing or confidence is quantified, it gives the impression that developers have more predictive ability than they really do. And remember, past performance cannot simply be projected on to future endeavors unless the work is extremely similar, in which case it might as well be automated.

Value Stream Architect at Financial Technology Service Provider: 

Erik Gfesser "high confidence means either similar work has been performed in the past...but remember, past performance cannot simply be projected on to future endeavors."

Would you reconcile these two parts of your response please?

Gfesser: Sure. High confidence is one thing, an accurate prediction is another. These aren't equivalent.

Value Stream Architect at Financial Technology Service Provider: 

Thanks. I tend to subscribe to the idea of probabilistic forecasting. I have found that using past performance is very informative and useful in forecasting future work. When comparing methods (estimating vs forecasting) side by side for periods of time, forecasting models were far superior. The kicker for me was the amount of time the two methods require. One requires no additional time from developers and the other did. Not to mention the psychological safety violations imposed on the team, the additional transition layers require to turn arbitrary sizes into meaningful time values and so on.

I would rather have the team focusing more on understanding the problem they are trying to solve and breaking down that problem into smaller problems than worrying about putting some estimation figure on it. 

If you are able to direct me to some piece of work that creates a good argument about how humans are good at estimating things, I'll reconsider. Until then, I'll continue to leverage statistical analysis and let math do that job for me.

Gfesser: Developers aren't adept at estimation, and my comments weren't in defense of estimation. I was simply commenting on making use of percent confidence in response to the other poster. Yes, statistical analysis would be more accurate when applied to lower degrees of novelty. After all, confidence intervals are a statistical concept. And breaking down problems tends to decrease the novelty of each component, increasing predictability. But as you implied, what provides greater value: estimating how long it will take to implement a solution, or actually performing the implementation? I think we can at least agree that the latter is the true goal.

Community Comment: Part 16

The comments I provided in reaction to a community discussion thread:
https://www.linkedin.com/feed/update/urn:li:activity:6883455289505521664?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6883455289505521664%2C6883466108553244672%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A6883455289505521664%2C6883474864909377536%29

Founder of Taproot Foundation and Imperative: Need your advice, please. I buy and get a lot of books as gifts - which I love. My new home office and frankly our house is starting to be overflowing with them. I did a purge last year but there are still piles of books. I hate clutter - it makes me anxious. But I also don’t love digital books. How do you manage your books? Any tricks?

Global Top 100 Influencer in Strategy and Analytics, and Talent & HR Strategy Transformation Leader at IBM:

I hear you!! We’re book rats, and I’ll give you a kidney but not my books. So, living in a New York City apartment compounds my problems. We have bookcases in every room to help..but it’s an ongoing battle.

Regardless of source (gifts, etc.), I try and purge everything that doesn’t fit in the following categories. I also do read a lot online with the Scribd app which helps me manage immediate access to something I want to read without clutter.

I classify my books as:

1. KEEP - because they are sentimental in value, some really old…books I owned as a child, others rare and valuable, some obscure. Too many of my books, alas, fall into this flexible, elastic category.

2. REREAD - books I read often and dip into, just for fun…books and characters I love like people.

3. ASPIRE - books I want to read ..these are stored on my bedside table. So by default; I cannot have more than 10-12 of these at a time. I have 10 right now.

4. REFER - needed reference purposes. This is the most useless category in my opinion as all of these references can be accessed online, and these books are read rarely. Other family members are attached to some of these books; so they stay.

Founder of Taproot Foundation and Imperative: Great categories! Very practical!

Gfesser: You've come up with some nice classifiers, essentially the same as mine! Two additional ideas to consider. (1) My books in the "keep" category are in storage. Since these aren't books I plan to re-read or reference, I get these out of the way. (2) My books in the "aspire" category (which I call the "currently reading" category) are broken down into four subcategories, using baseball nomenclature (and a little German) for my blog readers: "At Bat (Schnell)", "At Bat (Langsam)", "On Deck", and "In the Hole." As I mention in the quarterly reading list updates on my blog, I update these lists throughout each three month time period in an agile way, providing a bit of accountability while at the same time demonstrating that priorities often change.

Global Top 100 Influencer in Strategy and Analytics, and Talent & HR Strategy Transformation Leader at IBM: 

Erik Gfesser, love this. Shall look for your blog.

I also have to confess to an unwarranted and egregious sentiment of “visual satisfaction” from my “keep” category. This is one reason that prevents me from storing them. For example - I was able to find a copy of “The Malachite Casket”, an obscure collection of Russian folktales, which I read as a child in India. I also have the moldy and tattered original, that my sisters and I read. Having these two copies of the same book around, where my kids and I can see them, gives me joy. And alas, contributes severely to my dilemma.

Founder of Taproot Foundation and Imperative: Erik Gfesser you had me at ‘baseball’

Community Comment: Part 15

The comments I provided in reaction to a community discussion thread:
https://www.linkedin.com/feed/update/urn:li:activity:6884136604764565505?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6884136604764565505%2C6884184734960775169%29

Director at Executive Search Firm:

Do not hire an architect if you want them to be sat writing code all day long!

Sounds simple, right?

Well, as crazy as it sounds, almost every week I speak to architects who have been hired by companies who then fail to give them the chance to actually focus on architecture.

Although I appreciate the talent market is incredibly challenging for a lot of companies, do not put round-pegs into square holes.

Even if there are technical architects, or "coding architects" who enjoy contributing to the code base (and vice versa for developers with architecture), architects and developers are not the same.

Stop wasting everyone's time and hire what you need!

Gfesser: I've learned that the term "architect" can mean many different things depending on the audience. This situation has gotten to the point that a fair number of firms even refuse to use this term due to some of the audience assumptions that are often made when hearing references to it. And adding qualifiers to "architect" often doesn't help much. While every company is arguably now a software company, many of the terms being used in industry simply aren't standardized. As such, job descriptions should be explicit as to what is expected of these roles, and the individuals writing these job descriptions should be close to the work being performed to help ensure accuracy.

Community Comment: Part 14

The comments I provided in reaction to a community discussion thread:
https://www.linkedin.com/feed/update/urn:li:activity:6871126959674400769?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6871126959674400769%2C6873206176721506304%29

Data Warehouse Architect & Developer at Healthcare Data Consultancy: I keep seeing this again and again: databases like Snowflake, Redshift, or BigQuery that are called 'Data Warehouses' when discussed in the context of acquiring them. They are not.

What they are are 'Analytical Databases': they are tools / technology fit to store data structures in to be used in an analytical context: write once, read many, good in joins, aggregations, etc...

A 'Data warehouse' is WHAT you can decide to build using these tools: a 'subject oriented, time variant, non volatile collection of data / information for analytical decision making'. Thus, Data warehousing is about implementing data architectural patterns for analytics. When building a good 'Data Warehouse' you need many more tools then only an 'Analytical Database'

Why is this important?

We can also use an 'Analytical Database' to make a complete mess of everything, to build something that definitely is NOT a "data warehouse".

I really believe we should stop naming technology as something we can BUILD by USING that technology.

After all, we also don't call a HAMMER a CHAIR, right? Using this as an example, it's immediately clear how weird this would be...

We could say: 'it is only language', who cares?

But IMHO, when working in this field of data / analytics, if there is one thing that we should try to do is use our language in a consistent way.
If not, we're really making it more complex then it needs to be...

Gfesser: Good post. Another way to put this would be to simply differentiate between infrastructure and solution. In working with some talented infrastructure folks over the years, I've often commented that with respect to data-intensive solutions, infrastructure isn't synonymous with data architecture. Data architecture is the implemented solution (models, code etc) making use of this infrastructure. Data models and data distribution strategies for Amazon Redshift, for example, aren't things that come out of the box with a Redshift deployment. Why? Because the data and use cases need to be taken into account.

Co-Founder at Data Engineering Firm: Well said. What is your take about 'data mesh'? Can I buy a solution for that?

Data Warehouse Architect & Developer at Healthcare Data Consultancy: Hi [Co-Founder at Data Engineering Firm], I would say the answer to this is a hard 'NO'. Data Mesh is such an emerging concept that it is still somehow unclear WHAT is exactly is and even more, HOW to practically implement it. What is describes is a vision of a fully decentralized data / analytics architectural pattern. A pattern where Data 'sets' are threated 'as a product'. Where ownership of data products are pushed down to 'the business'. The main work we need to do to get there has to do with culture change....

So, this example of a 'data mesh product' can, - by defacto -, NOT be fully true: https://www.starburst.io/

Senior Cloud Architect Data & AI at Microsoft: [Data Warehouse Architect & Developer at Healthcare Data Consultancy] lets agree to disagreement.

Data Warehouse Architect & Developer: ok, let me rephrase my answer: you CAN 'buy' different tools, solution components and write software that can be used to build a data mesh with. A data mesh itself, just like a data warehouse is not something that can be bought. Furthermore, there is no SINGLE technology / tool in existence that can be used to build a data mesh with.

Senior Cloud Architect Data & AI at Microsoft: [Data Warehouse Architect & Developer at Healthcare Data Consultancy] agree!

Co-Founder at Data Engineering Firm: [Data Warehouse Architect & Developer at Healthcare Data Consultancy] I think the same way. Data Mesh is not something that came out of the box. Neither the data warehouse, data lake, Lakehouse. But some companies are taking advantage of the new buzzwords in the space. I like the data mesh concept. I like Starburst. But they are not the same.

Gfesser: My team and I built a hybrid of a third and fourth generation data platform in 2019-2020, with data mesh being the fourth generation. As some other commenters have said, it takes multiple products/services and custom code to create a data mesh. A shrink-wrapped data mesh cannot be purchased. And if and when such a product could actually be purchased down the road, by that time we will already be well on our way toward a fifth generation. For anyone interested, I wrote a blog post on this topic:
Building a Data Platform on AWS from Scratch: Part 2
https://www.linkedin.com/pulse/building-data-platform-aws-from-scratch-part-2-erik-gfesser