Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

  reversethis-{gro.napc} {ta} {nbsanoj}
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Friday December 07, 2007
03:43 PM

The Truth, The Whole Truth and Nothing But the Truth

[ #35062 ]

I am working for a client where most of the assignments we get are about letting the customer get online access to back-end systems and data related to their relationship with the client. This mean customer data, services etc.

We implement the front-end in a combination of (HTML) XSLT and Perl everything we call is neatly wrapped in a lot of Java, which calls some other Java, which sometimes call proprietary APIs based on a variety of back-ends.

I learned the other day that this sort of architecture is called a 'Totem pole' architecture.

Well anyway, things do however work, but I see one significant flaw in the system in general.

We want to give the user the best user experience possible. One thing is extending our part so more and more stuff can be accessed online. This is good and we are slowly progressing on this part. But sometimes when we start a new project we need to build a new totem pole. This part is improving but still implementing even smaller things take a lot of time and you grow tired of the projects before they are done.

With each layer (or head) in the totem pole, the programmers have attempted to generalize instead of specialize, this is often a good idea and sometimes interfaces can be reused. But mostly we aim for one client, namely the online framework.

I think it is a very good thing that the programmers attempt to generalize, but their APIs should be implemented in regard to the clients. We have experienced several times that APIs are simply not useful from our perspective, since even the simplest of operations require several requests, either we need to gather the data from several interfaces or even services or the APIs simply do not offer everything we could use since somebody never thought that certain data would be interesting to us - the more relevant data we have, the more informative we can be. The more client oriented APIs we get the better user-experience we can implement.

So in my opinion tighter coupling seems to be necessary in this case. We want to be able to tell the truth to the customer and show them the real picture of what is going on and yes we want to do so before they go away.

Another hard thing I have think I mentioned before it getting the back-end developers to understand the importance of the APIs and that we are the client - and the client is always right, right?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • “In programming, everything we do is a special case of something more general – and often we know it too quickly.” —Alan J. Perlis, “Epigrams on Programming”

    The first time you do something you have no idea how to solve the problem yet, so you just do whatever you need for the task at hand. The second time, you copy your first design and tweak it to fit the new requirements. The third time, you go back and replace special-case functionality with hooks and indirections w

  • I agree with your observations, thanks for commenting and sharing your thoughts.