Research and Destroy » derlanders

For the sake of architecture…

derlanders — Wed, 21 Jan 2009 15:27:49 +0000

If it is simple, expand the problem by adding additional concerns. Justify this by future extensibility and maintainability. Incite and nurture confusion about what may only look simple but is likely to turn out complex later. Later, argue against it by pointing out that the additional complexity never came and no one knows which code is used at all.
If it is complex (or likely to become complex after the prototype phase), analyze half of the complexity and implement one half of that. Justify with completion time and pragmatism. Later, argue against because maintainability requires pain suppressors and protective eyewear.
If it has many features, have modularization by layers only. Justify with build and deploy overhead. Later, argue against the efforts going into a complex build system that was never needed because the layers are always built and deployed together anyway and no different usages, development cycles or versions exist.
If it has many layers, modularize by features only. Justify with agile deployment. Later argue against feature-based modularization in general because shared components have to be versioned and/or redeveloped so often.
If both of the above apply, use arbitrary names and have cycling dependencies between layers *and* between features. Justify by saying that you will build the whole lump in one piece anyway. Justify with easy deploy. Later, argue against modularization in general because with all those cyclic dependencies refactoring would take ages.
Never modularize by abstraction tier. You don’t need to justify that, nearly everyone will be with you, here, because concrete and explicit is always better than abstract and configurable. You could argue against it when having base components for more than one application. But usually this is not a problem and you will be expected to develop everything again for the second app anyway.
If something is expected to be used at exactly one place, have 4 or 7 classes describing its exact lifecycle. Use unary vertical inheritance or delegate to a stack of static utilities that do it. Justify with reuse. Later, argue against OO because it makes your code less understandable.
If something is used everywhere in different contexts, have it copied, pasted, developed anew each time or at least made static to avoid dependency inversion. Justify with redundancy and damage control. If someone tries to convince, trick or force you into abstract services that use parameter containers or commands, at least have concrete methods to keep it from sinking down the dependency tree. Produce static utilities that carry the name of the desired pattern (e.g. Service, Command etc.) so you can say you did it enterprisey.
If something is the same all the time, have it configure itself by a proprietary configuration file format in a virtual, internet based filesystem on a remote grid. Justify with configurability. Argue against by pointing at the myriad of undocumented config files.
If something is likely to change or be used in a different context, put up a couple of assumptions for the least probable case and hardcode these in a static and final fashion. Have all public methods finalized and all internal methods private. Justify with safety. Later, write a wrapper around them that fuses some concrete components into one, even more concrete component.
If you are working platform-independent, try to have as many dependencies to certain environmental settings as possible. Use the OS to configure your application if you can’t do it in hardware. Hidden OS particularities like new File(“C:\\”) can help. Later, argue against platform independent code because it is slow. Then use another platform-independent system.
If you lose control of your low level implementation, wrap it into a slightly changed interface on the same abstraction level and lose control of that as well. Then delegate that to a static utility with the same “interface”.
Try to have interfaces as concrete as possible. Use @implementedBy if you can. Have all possible usecases of a topic defined in one interface. Justify with comprehensibility. Later, argue against interfaces. They are emballage, bulky, stop your code from compiling and do not do anything.
If you really must have terms like module, service, application, scope, mandate, deletion, replication, staging or plugin in your application, try to introduce them into your code as late as possible. Justify with development speed. Have the “new” thing be parallel and concurring to the “old” thing. Spread among these strategies evenly.
Have as many things as possible require specific knowledge. If you have the choice between writing automation or writing documentation, choose email or your local hard drive.
If something is retrieved dynamically, have a static and final reference to it. Justify with coding convenience. Argue against dynamic retrieval with runtime/network restraints when high availability does not work and strange Errors show up. Recommend a different technology.
If something is static and final, have it initialized by a timer thread, a second application or by special parameter values in regular calls.
Use reflection for public business methods, within the same layer and abstraction level and especially for initialization. Have everyone hate you for it. While reflecting, do not annotat. Use concatenated naming conventions instead.
Ban reflection for lookups and configuration in abstract components and code that handles application components. These calls should always be explicit and concrete, with business names and long, scalar parameter lists at best.
Use fields for temporary calculation results and then transfer these into static methods by either a long parameter list or a proprietary backpack pattern. Make the method synchronized if strange things occur. Use delays if they continue to occur.

Krieg!

derlanders — Mon, 10 Nov 2008 14:20:23 +0000

Too lazy to architecturize your projects?

derlanders — Fri, 17 Oct 2008 14:15:56 +0000

Here is the solution:

How to survive a discussion of principles

derlanders — Wed, 11 Jun 2008 12:35:05 +0000

There are so many Books about more or less ingenious design patterns, engineering guidelines, modularization, framework usage etc. no one could ever afford the time to actually read one of them. The main point in all of these efforts is widely the same:

I don’t want to do more work than I have to.

Which is, in fact, the principle of all technology, up to the point where having spent efforts in technology finally frees us from the efforts of the task itself, leaving us just with the efforts of fixing that technology when (if would be nice here, but is inappropriate) it breaks and the effort of finding something meaningful to do. It unfortunately implies “If I can drive a car with three wheels, why should I bother buying the fourth?”

So why the heck can’t I just…

I mean, you get a task. Say like “Write an online application”. What you want to do is get rid of it forever. What your company wants is to get rid of it soon.

So they order you to get it done as soon as possible and you will be spending time on it forever. Face the fact.
And the first solution that would come to your mind would be: “OK, if I do this as simple as possible, I won’t be doing complex errors and be done with it quickly.” Which is a correct assumption. For one, finite Task.

This is, where multiplicity comes into play. You won’t be doing one Task in one context. You won’t be done with it, ever, either. And the first one coming after you will most probably have to do it again in a slightly different fashion. And there is a word for multiplied simplicity: Chaos.

There is a certain amount of complexity that a System will always have, defined at least by the complexity of the tasks it has to perform. There is no way to eliminate this complexity, not even with Object orientation, 4GL and UML. So what happens if you seem to have eliminated complexity is that you actually shifted it somewhere else. Which can be a good thing, once that “elsewhere” is in the domain of your customer’s organization and they can live with it. Or inside some framework voodoo.

Calling things differently or avoiding to name them at all does not eliminate complexity either. It just takes away any possibility to handle them. If your application does not have explicit Tiers (Yay! We have a one-tier application! That is only a quarter of what a 4-Tier application would cost us!) it nonetheless has implicit ones, and usually more than you would imagine. If your application does not employ a model (saved efforts incoming!) it will have an implicit model nonetheless, and even better, it will have several models describing the same thing, once that thing is used in two contexts!

We have a developer here that spent much time painting tables with fields to find implicit models for which no classes exist.

So why bother with architecture, modularization or reuse at all? I mean, even if your system starts with minimum complexity, future evolution will soon drive it into entropy anyway! And yes, this is an effect that can not be avoided by any means we here possess. Any concept of reuse requires overhead, abstraction and configurability which makes the would-be reusable component even more complex. Any concept of modularization requires much work on how these modules interact, are composed, packaged, defined and you have to do much work just finding out where to put your stuff.

Fun, isn’t it? We actually add more complexity to an already complex system, to be able to view it in a more simple way. Isn’t that ridiculous? No.

What we can do, is shift complexity away from the evolving spots. We can move it out of the multiplying part of the system, which is usually defined by the features. Since complexity is there, and cannot be done away with, we have to face it somewhere and make sure that it is faced only once. So there are complex components, difficult to understand, cryptic, like many components of software tend to become when left alone for a couple of years, but we have them in their own biotope of complexity, and most important of all, we have their complexities separated, able to be handled one at a time by different people.

It is not the aim of modules to enable old, smelly code of old to work forever, but to have clear places to cut once parts of that code fall to the teeth of time and have to be replaced. Furthermore, we have Modules to enable composition of more than one product (or variation thereof, like a staging installation) while using the same, tested implementation with a different configuration. Featuresets and other terms known to multiply are allowed their own module to keep the multiplying stuff out of their dependencies. This ist costly, but it costs less than multiplying everything in every code.

We do not produce future code that handles all possibilities of future extendsions, but we provide valid rules for extending the system, at defined places, with defined terms and common basic functionality. So then the future code may multiply and change as much as it wants, as long as we are able to handle these multiplying components at all, our basic system remains stable, in fact, it gets even more stable with each new component that uses it, and it actually stays… simple.

So everytime I drop a design abstraction for the sake of simplicity, I should take a clear look where it actually went, because I can be sure it will bite me some time.

When I read a book about object orientation, the first argument for OO is “Encourages reuse of code”. No. It doesn’t. It enables you to do reusable components, but these do not besome reusable by just writing “Class” somewhere atop your old code.

My oh my what have we here…

derlanders — Tue, 22 Apr 2008 10:03:45 +0000

Did you ever get scared about modern Software being all too intelligent, that it would finally take control and such? Don’t be.

A THING emerges…

derlanders — Fri, 11 Apr 2008 18:26:29 +0000

Really… after all that architecture nonsense and fruitless “platform” development (like in “fill the svn with a crapload of thingies which are ignored and reimplemented anyway”), the old question: “Yeah! But is it ART???”. How could web application development possibly benefit froum our efforts?

Today, I came across my first new component that did, for a change, require no big deal of “platform” implementation. In the unyielding hope, that this at one far day might become the rule and not the exception, I’d like to shed some light on the details.

I started with the query. That is a good way to start, one gets a good hold on what to expect and what to pay for. Since we are doing a rewrite of existing software, I held my breath and dove deep into the existing PHP. To find a previous implementation in the action code that pretty much resembled a query along with some decision code and a “routine” (Piece of code set apart with blank lines and actually sporting a comment) to determine bar width for some kind of bar diagram – fine.
The query wasn’t too complicated, basically a PageableListQuery, for which a base implementation exists. In my concrete query, I put in interfaces for Cacheability and the data provider datasource where it should be executed.
Once the query was there and I had determined the query parameters needed, I realized that the return type of that query actually missed in our Object model. Since our BOs do not have any Dependencies, I unscroupulously added a new class asking questions later.
The class stayed small, the table actually looks full of data but in reality it only has a few colums plus it is sortable.
Suppressing the urge to do something entirely different first, I introduced a pretty stark junit test case that asserts at least the query string that goes to our data provider and checks if it is possible to get a result at all. Of course, the result list had zero elements and some Exception hit the wall next to my head.
There was a new BO Type, so I had to write a Mapping for it. Since I am the first and only person to request this BO type, my Mapping goes to the class annotation as default mapping, go me! And since it is an unspectacular list mapping, I even get to retain the GenericListMapping for the iteration part and only have to implement the single object part, which is nice because this is very unlikely to produce strange errors. Mappings could be far more generic and self-contained, but our data provider has a rather odd object design and it is better understandeable to have some repeated code than some cryptic extension code to a generic mapping where no one knows how it works.
With the generic list mapping annotated to the query class and the item mapping to the BOM class, the platform knows enough to get me datah! One day soon I’ll make GenericListMapping default for all ListQueries, but that’s not so easy.
Tried the test case again. Yay! One field was not mapped correctly, but the result graph was o.k. It is good to know that a query executes correctly without having to deploy the application to JBoss to find out.
Added some meat to the test case, but it is not wise to make the data content tests too sharp, it is not our Job to ensure data quality of our data provider which more often than enough irritates our tests. A result list with more than one entry and the first entry object with some correctly mapped fields in all graph objects was enough.
Started Struts action implementation. Since the table does not have any complicated decision code and no data rearrangement voodoo either, I didn’t have to add much to the class. There is a default implementation for actions that display a List of BOs called PageableListAction which I could extend, all I had to do is add the action parameters, a method that creates the query and passes the action parameters to it (if that does not come from the configuration) and a little method to calculate the bar width. Since this one does not produce an array of widths but only one result per BO, it shrank down to one line.
When looking into the navigation.xml config I saw that The Ralph of God had already left His traces. Normally, I would have to add a menu point in the main Navigation and four tab navigation entries there, pwith the possibility to configure default parameters or query implementation.
in the struts.xml, someone had done similar, but I still had to add result entries since the JSP (can’t blame them, the pages don’t exist yet, not everyone is adept at precognitive software engineering) since we do no magick in the struts config, I can forget about that file from now on. Actually, I do so from time to time, the PostIt at my monitor labeled “Remember that there is a struts.xml” surely helps.
Speaking of JSPs, they were the worst part that time. Usually, there is a premade file from the HTML Ubergurus which dwell on the surface that I can cut and paste, put some and here and there and be done with it, but these were a little strained with other, more important stuff so we had to extract from the old system. Which is what I did, the templates of the old system are well separated from the “action” code (that is a good thing) and it looked easy enough.
There are 2 JSPs now, one for the page and one for the component. It is the first and presumably only usage of that component, but concrete implementations of entire pages always attract later changes that fry the recyclability. The component jsp is called from the page JSP by and that’s it, since I do not require any additional parameters yet that I would otherwise put in here.
Added standard component JSPs for taglib include, header and footer to the page and and tab navigation along with a page count/progression control to the component JSP, whatever crash should occur on that page, it will at least look nice from now on.
There should be a test case for that one-line bar-width calc method, I know. I promise, there will be some time in the future.
Smoke test. Bäm. Some THING emerged. From now on, bugfixing.

We were wrong all the Time!

derlanders — Wed, 02 Apr 2008 09:37:05 +0000

If you’re not familiar with FAD, then you’ve been missing out. Essentially, FAD is a fundamental paradigm shift over the “traditional” and “neo” ways of building software. Not only does it surpass every other software development methodology out there, it solves every problem there is to building software. And then some.

The FAD Manifesto

I. Front Ahead Design
The essence of FAD is conveyed directly in its name: design your front-end/user-interface first, ahead of everything else. The customer could care less what’s behind the scenes, so long as it looks good and does what it’s supposed to. Deliver a working front-end first and then Do What It Takes to fill in the functionality gaps.

II. Do What It Takes
Other methodologies are great at delivering excuses. How many times have you heard (or have been told) “we can’t do that here because it could throw off the whole design?” In FAD, you just do it (that would have been the bullet point, but Nike has it trademarked). To get it done, you Do What It Takes. Your customer will love you.

III. Code Light, Not “Right”
A traditional methodology calls a complex framework with layer after layer of objects. In those ways, adding a simple value to a form can be a monumental task, requiring it to be added to every single layer. Does that sound right? Proponents of the other methodologies will tell you it is, but what about your customer? With FAD, you just Do What It Takes to add the functionality to your interface. No more.

IV. “Throw Away” Diagrams
Think of all the Visio diagrams you’ve drawn over the years. Sequence diagrams, context diagrams, flow charts, and so on. Was that really productive? Did your customer ever see any of those? Were those diagrams even relevant after the system was finally developed? Didn’t think so.

In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work. And there is no formal modeling language to battle with: just Do What It Takes to draw and explain your design to other developers.

V. Life Is Short (a.k.a. Patchwork)
The average software system has a life expectancy of seven years. No matter how “properly” the system is designed from the start, within the first year of its life, maintenance programmers unfamiliar with the complex architecture (and having no help from out-of-date documentation) will turn the system into a complete mess with bug fixes and change requests.

In FAD, this isn’t even a concern. We know the short life span of a system and develop every feature (from the interface) as a patch. Maintenance programmers can come in and Do What It Takes to add their patches. In FAD, we don’t even try to stop the aging process. We encourage it.

VI. Learn To Deal
Many other methodologies focus on delivering “quality” (as in “bug free”) software. And guess what: they fail. Miserably. No matter how hard you try, software will have bugs. In FAD, we just learn to deal with it, and we encourage the client to do the same. So what if the application crashes when you click that button that way? Don’t click the button that way, and learn to deal!

VII. Be Environmentally Conservative
In the real world, there’s only one environment: it’s called The Real World. So why do some methodologies invent these counter-intuitive, bizarro environments called “QA” and “UAT”? Do architecture firms construct an entire house before building an addition on yours, just so they can “test” their building skills? Of course not, and neither should software developers. In FAD, there’s only one software environment: Production. Anything else is pollution.

FAD Application Design

NOTE: First and foremost, understand that the FADAD is merely the preferred method of building applications. Because in FAD, we do what it takes, a lesser or more in depth approach can be used as needed.

Many of the tenets of Front Ahead Design are based on the failings of other methodologies. FADAD is no different, and draws some of its key facets from the archaic Model-View-Controller architecture. In MVC, there are three different components: the Model (the data), the View (the UI), and the Control (everything else).

If you think about it, two of MVC’s components are nothing but dead weight. All anyone – including the client – really cares about when all things are said and done is the View. Therefore, in FADAD, our guiding architecture model is simply called “V”:

The H/YPE Framework: The FAD Developer’s Best Friend

If there’s one thing that’s frustrated just about every developer out there, it’s “untouchable” library code that almost does what you need it to, but not quite. For FAD developers who chose to use the H/YPE framework, this is not a problem.

Unlike the stodgy libraries of yesteryear, H/YPE is not a “compiled” library. It’s a set of cross-language codefiles that can be copied to any application, and is designed to “live” with that application for life. Don’t like that 48 plus 92 is not 4892? No problem! Just edit MathHelper. Here’s a small subset of what comes in H/YPE:

HYPE.StringHelper – all sorts of functions like IsEqual, AreEqual, Add, Subtract, Join, DoubleJoin, Encrypt, and Decrypt

HYPE.VHelper.HTML – the ultimate HTML library including functions like WrapInCENTER, UnHTML, ToHTML, and ScriptBlock

HYPE.Audio – everything you’d ever want to add audio, including Beep and BeepMore

But Wait, There’s More: Certification!

No, I don’t mean to sound like our good friend Ron Popeil, but before wrapping things up here, I wanted to tell you about the latest excitement in the world of Front-Ahead Design: certification!

Just last week at the International FAD Conference in Azerbaijan, I joined several other FAD leaders to formally announce the first official Front-Ahead Design certification program: the Fadstronaut certificate. Why Fadstronaut? Because we felt that the astronaut was the best analogy for the challenges and difficulties that FAD software developers face each day.

Becoming a Certified Fadstronaut is easy, but not too easy. All you need is one year (1,000 hours) of verifiable FAD development experience, and you’ll be eligible to sit for the Fadstronaut certification exam. Score in the 50th percentile, and you’ve earned the designation Certified Fadstronaut!

I hope that gives you all a good idea of what FAD is all about. Believe me, there’s a whole world more of FAD out there. That said, I hope to see some of you soon at the Worldwide FAD Meeting in Buenos Aires next month!

http://thedailywtf.com/Articles/FrontAhead-Design.aspx

About new architectures and old filthy systems…

derlanders — Fri, 07 Mar 2008 16:56:24 +0000

http://thedailywtf.com/Articles/Jurassic-Programmers-.aspx

News from the 16ms frontier

derlanders — Fri, 07 Mar 2008 16:56:15 +0000

Yay! We were finally able to fake some posable statistics which show that the cache system we use is uber. Okay, uber against partial caching in the file system, but still superior by factor 24. (Sorry, should be 23, we are working on it) Below a test result table for a time test:

1337 ms" />

“It is all lies! Everything I took for real all these years – a lie.”

As it seems, firebug only measures the time needed for a http response to load, which means our previous results were somewhat wrong. And the results for the PHP system too. The processing time from click to the start of the response is not included in either system. Now we used highly sophisticated software tools to overcome this flaw and produced… interesting results.

Figures spat out by some testing automat have to be regarded with suspicion though, especially if it is a quickly clicked test. However, if these Numbers are right, the Average click time of our JBoss (in transwarp overdrive mode, with solid fuel boosters and native library extensions along with our supportive pedaling) is about 35ms, with an ugly peak of 70 ms. The peak of the php system is 10.

Seconds.

So if you take a look at the graph below, there are the two pointy graphs with the live system (blue) and the qa instance (green). The red graph (The JBoss system) does not look pointy here because of the 10 second peak from the live system which ruins the scale. (The red and blue graph drop to zero because they finished their 100 clicks before the QA system)