What is the primary thing we do as software engineers? Write code? Well maybe, but what is the purpose of the code we write? I would argue that the primary reason we write code is to fill some sort of need, that need might be making your life easier or more enjoyable, saving time or helping your company decrease costs, improve sales or improve customer satisfaction.
Software is expensive to write and maintain, but why? I will argue again because it’s written in “code”. Wikipedia defines code as:
In communications, a code is a rule for converting a piece of information (for example, a letter, word, phrase, or gesture) into another form or representation (one sign into another sign), not necessarily of the same type.
This generally involves translating the problem you are trying to solve to the programming language du-jour. I’m sure you’ve heard of the telephone game where someone tells a story, they tell that story to someone else and soon the story does not resemble the original. Software development is incredibly frickin’ difficult and if you are lucky enough to have the original “story-teller” know enough and tell you an accurate account of what your system needs to happen, will you interpret it correctly and translate it to code properly. Good luck. All the latest techniques such as agile and all its offshoots claim to make your software highly, well agile, adaptable to change. If you need to translate a moving target such as a highly complex set of business rules, today this is probably the right approach.
Before we get into my primary assertion that Oslo has the potential to be a game changer, please allow me to take a slight detour and explain an assumption and something I’ve learned over the years.
The most valuable asset you will have when designing a system is the model that describes that data and the relationships of that data within your system. This is the core premise of Object Orientation. With respect to time and changes in business operations, the behaviors, business rules and functional requirements will change, the data that is used by those components is the most static part of the system. Spend your time up-front beating up your data model and specifically they relationships between the data.
Let’s assume that you allow me to claim that the data model is the most important part of your system and you have accurately modeled that data that represents your organization or problem. Now what? You need to describe how that data behaves with respect to actions and time. This is could be described in something called a Finite State Machine. If done properly, our data model should be able to accurately represent the data for the objects as they transition between states. We need a mechanism to describe the conditions in which these transitions are possible as well as what additional behaviors are executed as they transition between states.
Now back to Oslo.
In my humble, yet reasonably experienced opinion this is where Oslo has the potential to become a game changer. Let me explain. Oslo has the potential to bring a fundamental shift not in the tools and technology we use to develop our systems but by providing a mechanism to facilitate a radically different approach in solving problems. It does this by letting us mere mortals quickly and easily build DSLs or domain specific languages without having to design lexers and parsers. Since this is a fundamental shift in our discipline, it’s too early to target DSL’s to our end users.
The DSLs we define with Olso should be used by the people that know the problem to describe relationships, business rules, functional requirements and behaviors in a syntax that they can read, write and understand. These DSLs will then be translated directly to something that can be executed without additional involvement of a “coder”.
I’m a coder, so what does that mean to me?
In this brave new world where we provide the tools for the people that understand the problem to solve their own problems, we the coders will have some new roles:
- Define a normalized data store
- Construct the grammar for the DSL
- Construct a generic and testable set of behaviors to be configured by the DSL
- Put the user interface on top of the application
This is obviously a fairly large topic that I’ll be expanding on in the next few weeks but let me close by an example of DSL you might be familiar with:
This DSL is intended to be used by an end user, but start thinking about how you could use this same concept in your application to configure business logic.
When a payment is received on an invoice, transition that invoice from Pending Payment to Paid and send a confirmation email.
If you had a mechanism that would turn that grammar into some sort of expression tree, could you provide some sort of engine to execute it?
Until next time
-ec
No comments:
Post a Comment