Because it gets you solving problems.
I've been reading a lot of papers and shifted my attentions over to self-adaptive systems since the start of the year. I've become familiar with different researcher's thoughts on the subjects, and the methodologies and tools they're trying to develop. They seem too disconnected from practice and abstract to be practical. So I'm going to build my own.
That's been the plan. I've been doing a lot of writing, for my dissertation, on how I'm going to build it. How it's going to be different. Why it's useful and will be a game changer, etc etc.
Then I did a random Google Search today:
http://avalanche123.com/blog/2012/06/13/how-i-built-a-self-adaptive-system/
Son of a bitch. I've been looking at this problem since January. I want to make it the brunt of my research focus. Earlier this year I collaborated with Fractal Innovations LLC to design a prototype...but I hadn't gotten a concrete deliverable out of it. Now Some Dude seems to be moving in the same direction.
OH NOES.
The dreaded graduate student nightmare: Invest a whole bunch of time and energy into a problem. Meet with your committee.
"Are you sure this is a problem? It looks like this problem is already solved..."
Not gonna let that happen.
So I read his post, ended up looking at Fuzzy Sets...and it looked kind of intimidating.
A Fuzzy Logic based Expert System?
The seems fine.
Building a framework to build Fuzzy Logic Based Expert Systems, rapidly, conveniently, and following best practice software engineering principles?
Seems hard, bro.
...What can I do?
But I decided to play with the problem. See what I could come up with. I tried to build a system that could process the first, seemingly simple statement:IF brake temperature IS warm AND speed IS not very fast
THEN brake pressure IS slightly decreased.
Being a framework designer at heart, my mind immediately tried to be a True Computer Scientist.
The True Computer Scientist
You see, the True Computer Scientist's brain is much, much bigger than yours or mine.The True Computer Scientist is able to see the generalizations and abstractions beyond a given problem.
The True Computer Scientist doesn't worry about piddling, puny, simple logic flows about brake pressure and brake temperatures.
The True Computer Scientist analyzes the structure of the statements, derives a general form that applies in almost any context, and builds The System that manifests the heart and soul of complex decision making in an uncertain world.
The True Computer Scientist solves problems at a level so meta that you're thinking of thinking to understand but you're still not quite there yet.
The True Computer Scientist uses recursion and abstract data types with strongly checked invariants to determine optimal solutions, seamlessly wielding matrix mathematics and monads while you're still trying to figure out what the fuck that means.
The True Computer Scientist is a God, Puny Mortal.
...and I am just a dumb chimp.
Do a thousand monkeys put on computers create Google?
But every time my mind comes upon a problem like this, it immediately tries to be the True Computer Scientist. My mind raced to develop a class for Rules, Antecedents,and Consequents. I thought about building an expression engine for evaluating nested rules...and the more I tried to solve these difficult problems analytically, in my head ahead of time,the more scared I became.Woah. This is A Big Problem. I don't think I can do this.
"Slow down there, stupid monkey. Solve this problem. The framework can come later."
Just like that, suddenly I moved from Saving the World and Getting the Girl to Make It to the Next Save Point. Suddenly that fear that I'd felt was subdued for a moment. I started solving the problem.
An hour later, I had a working prototype that solved that problem. Plus, along the way, I'd derived the abstractions I need to build the framework.
How?
Simple. I've studied a lot of software design and architecture. Now, I'm able to think in terms of patterns and principles.Which means that, as I'm making my bar turn green, I also say
"Ah, this is something that's likely to change. Instead of adding another property to this class, I'll add a Value Object that this Entity uses."
I write the domain logic in. When I see patterns in what I'm doing, I immediately refactor to a Strategy or extract interfaces. I end up representing First Class Entities like Sensors, just in trying to keep things DRY. I flow from
getting a temperature reading from a Speedometer --> having an Analyst analyze a Sensor using a Strategy--> to having an Agent act on a Perception using a Strategy-->to having an Agent perform an Action using an Actuator with input from a Perceptor.
Pretty Cool
TDD enables framework design. Rather than trying to come up with the optimal design up front, design emerges from the components involved. Even better, it lets you start solving small problems quickly, adding value as you scale to the intended result.I know that I've become a much better software developer as a result of focusing my technique and being willing to try a different workflow. I regularly meet programmers who are dubious of changing their workflow, and many times default to denouncing innovations in our space as "another Silver Bullet." I highly encourage them to give this material a try.
It also gets better the more you involve and integrate. Reading Evans' Domain Driven Design or Fowler's Patterns of Enterprise Application Architecture are fine, in and of themselves...but when you start building software integrating those concepts, and adding elements such as Kent Beck's Test Driven Development: By Example and Robert Martin's Clean Code, your very coding style and philosophy is tremendously improved. The whole is greater than the sum of the parts.
I'll be illuminating just how much perspectives can change in upcoming posts:
The Android SDK: Yet Another Successful Big Ball of Mud
HTML5 is an Abject and Miserable Failure of Responsibility and Design.
Stay tuned.
