Do-It-Yourself Software

"That looks too much like real programming!"

"Well, it's not quite rocket science!"

These are two of my favorite quotes from ex-colleagues.  

The first quote above is from over 25 years ago, when I was working at a software company called Omnis.  It had developed the first cross-platform (Mac and Windows) software development tool.  The tool included a visual builder, a proprietary database, and connectivity to all other contemporary relational databases, most notably Oracle.  My colleague offered this observation when asked why not use Java (which had recently been released) instead of the Omnis tool.

The second quote above is from 4 years ago, when I was working at another software company that provided an eCommerce platform.  My colleague offered his response when I asked him how easy it was to build custom solutions with the platform.  He then proceeded to talk about actual rocket science and his Master's degree in Aeronautics from Purdue!

While my colleagues' responses were clearly tongue-in-cheek, they each highlight the tendency that we, in technology, are inclined to overcomplicate things.  The fact that there was over 20 years between those remarks, suggests that, perhaps, not so much has changed.  Most, if not all, business-facing problems on which I have worked over my long career, did not need real programming or anything like rocket science.

Which brings us to the burgeoning low-code/no-code movement.  These contemporary tools provide another layer of abstraction on top of "real programming" and aim to democratize software development.  They do this by offering visual development interfaces that eliminate or reduce the need to code and understand complex programming syntax and concepts, replacing it with familiar drag-and-drop gestures and simple property assignments.

The fact that technology heavyweights Amazon (Honeycode), Apple (SwiftUI), Google (AppSheet), Microsoft (Power Apps), Oracle (Apex), SAP (AppGyver), and Salesforce (Lightning) all have skin in the low-code/no-code game, suggest that we have reached an inflection point.  

No longer does every application need to be viewed through the lens of the corporate Information Technology department and the all-knowing high-priesthood of software architects and programmers!

As such, perhaps we can think of these low-code/no-code tools as very distant relatives of COBOL (Common Business Oriented Language).  As its expanded name suggests, COBOL was/is more oriented towards "business users" than "engineers".  Don't be fooled, though, it still sports a fairly arcane vocabulary and syntax.

Intuitively, we all understand that smaller teams are more nimble and efficient.  A key promise of low-code/no-code is its ability to support this small team structure, reducing or even eliminating the increasingly over-specialized disciplines -- architect, tech lead, front-end developer, back-end developer, DevOps engineer, data analyst, business analyst, designer, QA engineer, project manager, scrum master, etc. -- within corporate IT.  The challenge of maintaining consistent messaging across these roles and disciplines is akin to the phenomenon of the Telephone Game/Chinese Whispers.

Over my long career in software development, I have always been struck by this industry paradox -- our mission is to encourage productivity and yet our choice of tools and process are often inefficient (for the job at hand).  In addition to implementing solutions in more traditional languages such as Java, JavaScript, PHP, PL/SQL and shell scripting, I have dabbled in the following tools that aimed to smooth away some of those rough edges and inefficiencies, and could, therefore, be considered predecessors to today's low-code/no-code generation of tools:

• Filemaker
• Omnis
• Kony
• jQuery
• Visual Basic
• Intel XDK
• Hypercard/Supercard
• Microsoft Access
• FrontPage
• WordPress
  

"Real programming" (and real programmers) will always be needed, of course.  Someone has to understand concepts such as pointers, memory buffers, static versus dynamic typing, polymorphism, object orientation, functional programming, instruction sets, data types, registers, and memory management.  However, that is not (and should not) be a requirement for most of the business automation that is being developed right now.  

I have always looked for ways to simplify business software development within my teams, either through improved tooling, process, management, or culture.  In my next blog post, I will take a deep dive and test drive the following low-code/no-code tools*:

• Airtable
• AppSheet
• FlutterFlow
• Glide

Stay tuned for my next post to find out which tool will make me the best citizen developer.

*This subset of the vast (and rapidly evolving) low-code/no-code market, focuses on general-purpose app development in the Google ecosystem.  This is the area that I'm currently most familiar with.  I plan to later create deep dive posts into more specialized low-code/no-code tools focused on AI/ML, web design, eCommerce builders, and business process automation (BPA).

The (Hidden) Dangers of Functional Specialization

Like so many things in modern life, software development has become an exercise in absolute functional specialization. That is a single-minded goal of increasing levels of specialization. Economic specialization, whereby an individual worker has a single function, is at the heart of today's global capitalist system. This phenomenon is described in Adam Smith's seminal book The Wealth of Nations.

Economic specialization encourages each contributor to focus on a single goal or very limited set of goals. The payoff is efficiency. Each of us becomes an expert in a single endeavor, enabling a "group of highly optimized individuals" to team together. The proverbial whole is greater than the sum of its parts. There are, of course, darker aspects to this specialization fixation, many of which affect the individual contributors themselves (monotony, lack of motivation, reduced artistic expression, dependency upon others, etc), but it is difficult to argue with the theoretical gains in efficiency of such a system.

Those same efficiencies and "economies of scale" that are a result of specialization must transfer to software development, right?

It has long been argued, in software development circles, that two of the foundational premises upon which absolute functional specialization is based are bogus. The first is that there is some sort of median productivity against which to measure each individual. The second is that by "adding more bodies" we will always reduce the effort of each individual. Each of these assertions has been largely discredited in works such as the Mythical Man Month. This book claims, instead, that the range of productivity amongst individuals is so vast, depending upon expertise and experience, that it is meaningless to try to establish placeholder estimates. Secondly, through a series of case studies at IBM, it shows that the expected "reduction of effort" by continuing to add resources to a team not only fails to materialize but actually has the opposite effect. In other words, there is an optimal size for a team...and it is not infinity! Although written way back in the 1970s, I believe that this book remains highly relevant in today's Web 2.0 world.

As with any engineering project, multiple disciplines must be mastered to ensure quality. For software development, those are typically defined as:

1. Analysis
2. Architecture/Design
3. Development
4. Testing
5. Maintenance
   

Conventional absolute functional specialization wisdom would have us believe that we should employ sub-teams of experts within each of these disciplines. It would also suggest that we decompose those sub-teams further. Perhaps we would create a "Black Box Testing Team" or a "User Experience Design Team"? Further, we might be tempted to create a "Back-End Development Team" or a "Java Development Team", perhaps even before we have defined the architecture? These tendencies toward absolute functional specialization, although logical in the abstract, reveal a subtle difference between creating software and creating something tangible. There is only one "raw material" used by each and every one of the software development disciplines: "words" (either written or verbal).

Think about the raw materials needed to build a house. Here are just a few examples:

• Lumber
• Brick
• Concrete
• Sheet metal
• Stucco
• Paint
  

Given the array of raw materials needed to build a house, it is little wonder that such a project results in teams of sub-contractors (foundation pourers, framers, carpenters, electricians, plumbers, etc). However, software development, in my opinion, is not nearly so complicated as we have made it...and there is just one raw material! Many of the aforementioned software development disciplines are the result of artificial distinctions. Why would someone who can develop software be unable to test it? Is it unreasonable to expect the business analyst to implement his "words" in today's software languages? Why should there be separate "Test Specifications" or "Test Plans" when each is really only a different lens through which to view the Analyst's requirements?

Since the publication of the Mythical Man Month, other factors have emerged (some simply as a result of the maturation of software development industry). These new factors further discredit the notion of absolute functional specialization:
- Democratization/technology mainstreaming: a much broader section of the population is exposed to and comfortable with technology
- Increased demand for software: including "Internet time" releases
- System fragmentation: open-source and other factors have led to a much wider set of tools, technologies and languages that contribute to each "software system solution"

In conclusion, I believe that there is such a thing as "functional over-specialization" in software development.

A better approach, I argue, is to empower a single team to perform all of the necessary disciplines. It is also important to stay current with the disciplines best-practices, allowing you to limit the toolset up-front. (Although common-sense, the "limited toolset" restriction is oftentimes loosened as a compromise that is felt necessary because a sub-team, for example, "only does testing".) Finally, it is critical to enable efficiencies not by defining further functional specialization but by instead enforcing use of a team-wide content management system.