Abstracting to the Appropriate Level

I was discussing frameworks, uml, object relational mapping and their contextual appropriateness to given application, and heard myself start to make the bold statement : “The architect, or designer, should abstract the problem as high as possible.”  But (this time), I knew what was correct and true before my mouth got to speaking.  “The problem should be abstracted to the appropriate level for the particular context.”

Ah, yes, I bring in the context again. As I had when somebody asked me which was a more powerful programming language, Python or PHP, and I had replied, “it depends in which context.”  On a server which has PHP, but no python support, I would dare to say that the PHP language would prove extremely useful in comparison to the unrunnable python code, as attractive and object oriented as it might be.  It’s over there in the leather jacket, hanging out with the Groovy scripts.

So, given a problem, the solution set can be framed, or constrained, by the relative difficulty of the problem, and the context of the problem.  It’s tempting to jump to conclusions, as we all like to solve problems, and relating to problems means transforming one’s own past experience to a mapping to the existant problem.  The solution just begs to be applied.  “To the man with only a hammer, everything looks like a nail.”

The first thing I should look at, as a contractor, is whether or not a technology solution correctly fits the problem domain.  It may very well fall into the domain of typical systems used by businesses who either had this problem in the past and solved it, or have never had this problem.  But the solution domain may contain the prerequisite for the systems solution. Often, a business process solution has to be addressed, and the systems solution will just fall into place.

But for some semi tech savvy entrepeneurs out there, it is more a matter of wearing the buzzwords, talking the talk, soup to nuts, applying the no brainer solution, for 24/7 availability and scalability and trailability.  “Is your software scalable?”  I just love this question.  “Is it fault tolerant?”  I know he’s studied up for this.  And he probably doesn’t want our team on this project, as he has already selected the solution he desires before he has even discovered the nature of the problem.  He’s read about JBoss and ORM’s, Hibernate, and knows a few people who are running this who seem to be free of the issues which plague him daily, and keep his tech support and ops staff busy.  So, he’s already sold on a solution, with no thought to the problem.  There’s just no reasoning with this guy.  And I am a little angry, because he had us travel up to meet him and his engineering staff, and had no intention of hiring us.  He was just wasting everyone’s time, so he could claim due diligence on his “competitive” bids, before wasting the company’s cash.  I felt bad for him, and wanted to do something, but knew it was not my place. They asked about our approach, and we said from what we had heard, we would want to study the problem, to understand the nature of the failure. Like, going through the log files, and the changelogs, and so on.  Not as sexy as J2EE on shiny new hardware you bought from that salesguy that took everyone out to lunch.  Log files just don’t make the cover of GQ High Tech Times.  But they do help to solve problems sometimes.

But despite the need to understand the problem, and abstract appropriately for the context, including a management gap or a shortfall in funding, I feel it in everyone’s best interest if I keep up with the nature of the solutions domains.  Hopefully I have made it clear that I do not propose a one size fits all solution in the least.  Patterns are not for every software problem.  Java is not necessarily better than Perl.  Keep that in mind as I go on.

I have been examining with keen interest the state of CASE tools, Rational Rose, UML Modellers, ORM mappers, Code generation tools, from the template based mapping solutions to homegrown xsl scripts.  Because whatever the solution domain is for the customer, the solution domain for me is often the same, in the workplace.  And it involves a webserver, a database, and a presentation layer, business rules, and workflows.  These may be orders, products, or information.  But in the end, it’s much the same.  As I have been shifting from a back end C++ developer, to a mid range Coldfusion/Java Flex/Flash developer, I have been searching for the best set of tools.  I’ll return soon with a listing of what I have found so far, and the pros and cons given the constraints and problem domains which I typically am situated with.




Comments are closed.

%d bloggers like this: