Unit Operations in Software Engineering

[John Konecny]

Hello everyone,

I’ve been exploring a more deterministic approach to software design. Unlike traditional engineering fields—where components like resistors or reactors are well-defined and modeled mathematically—software design often relies on heuristics that require years of experience to interpret and apply.

While we have design patterns, their implementation can vary widely. In contrast, data structures and algorithms offer clear standards—there’s little ambiguity in whether you’ve correctly implemented a linked list or quicksort.

I believe we can extend this clarity by modeling common software patterns mathematically and identifying a set of fundamental building blocks—what I’m calling “unit operations,” a term borrowed from chemical engineering.

I’d love your feedback on this idea, either through my blog posts or a presentation I gave:

https://blog-konecny.xyz/blog/2024/the-factorio-architecture/

https://blog-konecny.xyz/blog/2024/the-factorio-architecture-part-2/

https://youtu.be/gb4uqzRAGfQ?si=3nOFUtmK-GBhvV7x

I’m excited to hear what you think.

Regards,
John Konecny

[The Future of Programming]

Hello John

>> " I’d love your feedback on this idea, either through my blog posts or a presentation I gave:"

After reading the articles and watching the complete video

1- Thanks for sharing :D It's always good to think about software development in general and try to find some ideas that may help.

2- I don't see notable value from your proposal, the ideas seems good but not new, I could summarize what you are presenting as a question (What about using Visual Programming, Visual Components and Mathematical Analysis to have full design of the software) - These ideas are not new, they are research topics/directions that already exist. How is your proposal is different from a visual programming language like Bubble? or PWCT/PWCT2? 

3- Thinking of software using ideas from chemical engineering/unit operations belongs to (Metaphors for richer understanding of software development) - See book (Code Complete 2 - first chapter)

4- Algorithms are an open topic, we have many algorithms but there is open space for more/better algorithms. Algorithm analysis is a known topic. 

5- Many design patterns exist and help is software architecture, but more patterns could be discovered too

6- Components oriented programming (COP) is a known field

7- In software the limit is the sky, any way trying to know everything in advance means preset (limitations). 

I was thinking like you at some point in my life (trying to bring ideas from other fields to programming

One of these ideas is the Super Server programming paradigm - in the PWCT project, it may gives you some ideas about taking a more practical direction towards implementing your ideas to see if they works: doublesvsoop.sourceforge.net/pwcthelp/features/programmingparadigm.htm

If you did something pratical that simplify things, improve quality, reduce cost/time, etc. more people will be interested. 

Keep up the GREAT WORK :D

 

Greetings,

Mahmoud

[John Konecny]

Hello Mahmoud,

I've been giving myself time to reflect on what you've said, hence the delayed response.

1- Thanks for sharing :D It's always good to think about software development in general and try to find some ideas that may help.

Thanks!

2- I don't see notable value from your proposal, the ideas seems good but not new, I could summarize what you are presenting as a question (What about using Visual Programming, Visual Components and Mathematical Analysis to have full design of the software) - These ideas are not new, they are research topics/directions that already exist. How is your proposal is different from a visual programming language like Bubble? or PWCT/PWCT2? 

Good question. I would say it’s different from visual programming because, from what I’ve heard and observed from other developers, they tend to break down problems into smaller units of work (or unit operations).
To me, this process is independent of any programming language or paradigm. In other words, you will ultimately write your code as a series of unit operations, even if you're working in a low-level language like assembly.

3- Thinking of software using ideas from chemical engineering/unit operations belongs to (Metaphors for richer understanding of software development) - See book (Code Complete 2 - first chapter)

Is this the book you're referring too? I don't see a reference to chemical engineering.

https://khmerbamboo.wordpress.com/wp-content/uploads/2014/09/code-complete-2nd-edition-v413hav.pdf

4- Algorithms are an open topic, we have many algorithms but there is open space for more/better algorithms. Algorithm analysis is a known topic.

Agreed, but using mathematical equations to describe how an algorithm will perform on specific data and specific hardware is not something commonly done in the industry—at least not at the companies I’ve worked for.

5- Many design patterns exist and help is software architecture, but more patterns could be discovered too

I think design patterns should center around specific algorithms, and unit operations are simply categories of algorithms.
The problem I have with something like the Gang of Four design patterns book is that there's a lot of room for interpretation.

It can be challenging to say with certainty that you've successfully implemented a Factory pattern, whereas something like Quicksort is specific and well-defined—so much so that people are expected to implement it in interviews.

6- Components oriented programming (COP) is a known field

Could you give me something to read that gives a good definition of COP?

It seems like a derivative of object oriented programming.

I think unit operations are a part of all programming styles and paradigms.

7- In software the limit is the sky, any way trying to know everything in advance means preset (limitations).

I disagree that "the sky's the limit" in software—if by that you mean there are no restrictions.
We all have to deal with hardware and time constraints on projects, whether they’re big or small.

I was thinking like you at some point in my life (trying to bring ideas from other fields to programming

I'm curious. What made you change your mind?

One of these ideas is the Super Server programming paradigm - in the PWCT project, it may gives you some ideas about taking a more practical direction towards implementing your ideas to see if they works: doublesvsoop.sourceforge.net/pwcthelp/features/programmingparadigm.htm

Correct me if I'm wrong, but this seems like another programming language—just visual.
I'm trying to establish common equations that describe how algorithms behave on specific data and specific hardware.

If you did something pratical that simplify things, improve quality, reduce cost/time, etc. more people will be interested. 

I'm working towards that... These things take time to develop. :)

Keep up the GREAT WORK :D

Thanks!

Regards,

John Konecny

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software-design-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/software-design-book/5be118ef-c782-4f75-a235-5748ccf7b235n%40googlegroups.com.

[The Future of Programming]

Hello John

At first, thanks again for sharing your ideas/knowledge and opening this discussion

It's always a pleasure to contact with people who are interested in improving programming & software development.

>> "In other words, you will ultimately write your code as a series of unit operations, even if you're working in a low-level language like assembly"

IMHO, I read this as just another description of Abstraction, Libraries & Packages.

>> "Is this the book you're referring too? I don't see a reference to chemical engineering."

I mentioned the book to refer to the concept. We need to have better understanding of programming
and software development (including design, coding, testing, changes & evolution, etc.)
And we could learn from other fields/domains. So, I see what you are doing is a try to apply this concept.

I don't disagree with the direction, but what is new? 

When I watched your lecture, my goal is to learn from your something that I can apply.
What I mean while you are following a known concept/direction (bringing ideas from another field/domain), the result doesn't show something new/useful
that I don't know before and could change how I do my programming tasks in a different/better way.

>> "Agreed, but using mathematical equations to describe how an algorithm will perform on specific data and specific hardware is not something commonly done in the industry—at least not at the companies I’ve worked for"

1- Because (The Source Code itself) is the description
2- There is a difference between Mathematics & Software Development

According to my knowledge, Mathematics helps in theory, analysis, design, planning, etc. It's a thinking tool.
Software development is about implementation, reality, users, development teams, versions, evolution, testing, etc. It's a mix of Art/Science/Tech/Skill.

For example,
High income - lower cost = Profit (This is mathematics)
Knowing how to increase the income and reduce costs and what to do in the first place,
how to manage the company, employees, interact with customers, this is Business.

Software development is full of components/interactions/communications/etc. and is more complex than business (IMHO)

So, trying to say we will solve (software development) problems using Mathematics.
is like saying 

(Software developments problems are already solved so we have mathematics that can handle everything) --> This is not the reality as I know it.

>> "Could you give me something to read that gives a good definition of COP?"

While as you discovered many resources mention OOP, the concept itself is very simple to understand/explain and is more general.

URL: Components vs. Objects vs. Component Objects ∗

Author:  Prof. Dr. C. Szyperski

>> "I disagree that "the sky's the limit" in software"

This sentence means we have huge space of innovation at the level of what the software does and how it's implemented

>> "I'm curious. What made you change your mind?"

Because when we bring ideas from other fields to programming, we not only bring the good/useful
benefits provided by these ideas, we also, bring what is wrong/bad and sometimes we don't know
such things because the other field (original source of the idea) could miss such disadvantages due
to lower complexity. In programming, things could grow fast in a very dynamic and complex ways and
such scenarios bring new challenges and use-cases.  

When you bring a new idea to programming, you will have some assumptions about programming that will let you
think that this idea is good and will solve problems, but a common mistake is (limited vision) 

This limited vision could be based on thinking only about specific (particular domain) or (doing things in particular way)

but once people start applying the idea in different constraints, you will discover the truth!

So, the lesson learned is respecting the context in which ideas could be useful/good and propose ideas according to this context.

Greetings,
Mahmoud