[Rails] Is this an elaborate hoax/troll?

[David Johnson]

On Fri, 2006-03-31 at 08:54 -0500, Gregory Seidman wrote:

> } An architecture is a wonderful servant, but a terrible master.
> [...]
> 
> ...and I think that is an excellent definition of overarchitecting.
> Overarchitecture means that developers spend more time satisfying the
> framework's demands than the system requirements.
> 

I can accept that, with reservations.  To me, that still sounds like a
failure to understand architecture at all, with a resulting failure to
architect.  But I can agree to disagree.

> } A lot of times, the degree of dynamism you describe is actually a result
> } of a failure to understand the problem space fully.  That does not mean
> } spending a bazillion hours poring over some nimnul's powerpoint
> } presentations.  It means recognizing that complex solutions generally
> } mean that you don't understand the problem yet, and striving for a
> } simpler solution that encompasses the entire problem space.  
> 
> Oh, I completely left out the management issues that led to this. The
> project began (years before I got involved) with large chunks of the system
> being pushed into development before requirements had been written, and the
> framework was developed concurrently with them. It is only within the last
> year that the framework has stabilized and the developers have stood their
> ground on not starting to code without solid requirements.
> 
Your organization is starting to mature.  But, you have to be cautious
of the other extreme that leads to capital-M paper Methodologies and
endless meetings (sometime with evil Power Point presentations).
Instead, get your programmers out doing the work of the people whose
jobs they are automating for two weeks, then tell them the problem, and
then let them loose to solve it.  It's a novel approach, but it can
work.

> } In general, it really is easier to solve the entire problem than to
> } solve just bits and pieces.  Special conditions (even if they are
> } embodied in framework side effects) are generally a sign that something
> } is not understood fully yet.  This is true whether it is J2EE,
> } Rails, .not (sorry - .net), or even lowly COBOL.
> 
> It would be lovely if a high-level list of desired features for the system
> were available to developers. If such a thing exists, it certainly isn't
> available to us nor to the architect who built the framework. Without
> knowing what is planned, it's hard to be abstract in the right places and
> concrete in the others.
> 
> I experienced a similar issue in my first real job. I was tasked with
> building a new simulation and visualization frontend (in C++) for an AI
> engine. I was not told what future use the frontend might be put to, only
> that the existing one was too hardcoded. I wound up writing a magnificently
> abstract MVC system full of clean interfaces that was loosely coupled and
> automatically registered interface implementations at load time and
> instantiated objects based on a simple XML file format. It was a thing of
> beauty. It was also too complicated for the owner of the project to
> understand (granted, he hadn't learned how to use any feature of C++ that
> wasn't supported by g++ circa 1990), yet too restrictive to make it easy to
> split the UI and the simulation into separate threads easily.
> 
> If they'd just talk to us, we could do what they need. But they never do.
> 
Most of the time, I have found that the end-users don't really know what
they want until they see it.  It is our role as a support industry to
understand their businesses that we are programming for better than the
users do.  The turning point for me was when I was the entire IT
department (third hat), writing applications in support of my own work
(first and second hats).  

If the programs didn't work, the senior estimator (me) went to have a
hear to heart with the IT manager (me) and we made things work.  It
didn't matter that the user (me) didn't tell the programmer (me) up
front what he wanted.  What mattered was that in transacting business we
had discovered a weakness in the tools we had made that was costing us
money, and we fixed the tool to meet our needs.

Apart from multiple personality issues, that experience changed how I
view and construct software.  I became much better at anticipating
business requirements in general, and much more understanding that the
business requirements are often fluid.

I began building my programs to offer options and guidelines instead of
rigid rules, and in the process discovered that I was writing less code
that was both simpler and more effective at meeting the business needs.

I wish you good luck in untangling your product.  Been there, done that.
There is a light at the end of the tunnel, and it might not be a train.

David Johnson