A couple of years ago I was working at a start up and they had a “no jerks” policy that they eventually used to fire me. I personally thought that was unnecessary because if they had just said, “We’re not going to let you improve the software architecture in a meaningful way” I would have left. We were the “engineering” team, which you know I have a problem with already because we simply don’t “engineer squat” in software development. I mean, I want to but…hey, I need your help to do engineering.
The think I did that got them to…
Below are some tips on how to manage granularity within workflow diagrams, use-cases, and component creation. Each of these work products are notoriously difficult to size.
A partial list of the work products that lead to system components are:
CONCEPT MODEL: A model of the concepts in the business, sometimes presented as a glossary.
WORKFLOW: How work moves through the business and what processes are performed to accomplish the work.
USE-CASE: The activities and interactions with the system required to do the work.[System Components]
MANAGER: Encapsulates the complexity within the scope of a core use-case.
ENGINE: Encapsulates the complexity around…
USE-CASE: A business process or activity for doing work.
WORKFLOW: How categories of work flow through your business.
Categories of work? What the heck does that mean? When I think about workflow I often catch myself imagining that I was personally executing the business and going from node to node to node along the workflow. That is wrong. It’s not what a workflow represents. We should be thinking about workflows from the perspective of the work, not the people or automation (robots, nightly jobs, scripts, jobs, triggers etc) that perform the work. That’s how a “workflow” is executed.
[I’m still working on this story and will remove this when done.]
This is a quick guideline on how to draw diagrams that are just boxes and lines. Boxes and lines are very often used to show the architectural structural elements in software. Developers as a group are very bad at making these drawings.
Part of the problem is that architecture and design are 2% problems. Meaning that on any project they represent, at most, 2% of the effort. Ergo, no one is any good at it. And, should you find a way to be good at it you’ll be…
“The Message Is the Application (TMITA)” is an interesting design pattern. I’d like to discuss it’s challenges.
The inspiration for this post comes from reading the masterpiece Righting Software by Juval Lowy. In the book Juval teaches the basics of decomposition and Service-Oriented Architecture (SOA) and design. After teaching the basics Chapter 5 is an example. The example leaps off the deep end and uses TMITA design pattern. I wrote this article because book club discussions about the example made it clear that people were having difficulty following along. The reason I came up with is the complexity of TMITA…
I’ve not been coding as much as I should because as long as coronavirus has everything out of wack I’m trying to take care of some personal projects. But I am still coding and thinking about code. One of the things about being here at home is that I’m using my home automation stuff a lot more and make small tweaks to it. This means modifying code that I haven’t touched in more than a year, sometimes 5 years or more.
The experience of modifying code you haven’t worked on for so long that you don’t remember writing it is…
C# is not a functional language. I love C#. It can be highly productive. But there’s a dirty secret, existing code often sucks and every day others create more existing code.
Functional programming can help. It’s easy for it to be too complicated and there’s definitely a learning curve. I’ve noticed that developers that learn functional programming first and then are exposed to OOP/Procedural tend to be better at abstraction and logic, better at OOP, procedural, and functional.
Can we introduce just enough functional to be faster with higher quality but not so much that we can’t use existing frameworks…
TLDR; I demonstrate a common technique for making the most of C#’s type inferences shortcomings to do some functional programming.
When we want to apply multiple
I tried doing this in C#. Currying a function is fairly easy, and it’s particularly easy if all you need is a partial function as Jon…
Trust me when I tell you that your team’s first instinct will be to build a data service. Please resist the temptation. We’ll talk more about that in a minute.
You’re effort to build services should begin by documenting your business workflow. Not the workflow of one of your applications. We’re talking about the workflow of your business; the processes and decisions you would go through if doing your business manually.
The processes in your business workflow should map fairly well to your core-use-cases. These will be the core-use-cases because your business cannot live without them. You’re software has a…
<this is the place where I will put the description of “the system.”>
Please check back later
System design is it’s own set of skills and it’s constantly evolving. There is a great article by Monty Montgomery discussing “Escaping Appland” and how to build systems. Highly recommended.