Re: Building a framework in lisp for testing and feature documentation?

Peter Seibel wrote:


> While Joe Marshall is likely right that your company is just screwed,
> it's also possible that the main reason this bug/test-tracking
> database hasn't happened yet is that nobody who cares about it has the
> time or energy to do it. But here you are--you care and you believe
> you have the time and energy. (Of course you have a secret
> weapon--Lisp!) So I say go for. Worst case scenario, is you learn
> something before the company goes under. (Unless of course there's
> something else you're supposed to be doing in which case worst case is
> that you get fired for not doing your actual job.)

I've already realized that this is a project I will probably have to
tackle largely on my own time. As you say, if anyone in the company
believed it was important, someone would have already allocated the
resources to do it. I think the biggest reason it hasn't happened is
the CEO and CTO look at that kind of project and try to extrapolate
from their J2EE experience how much effort it would take. They
conclude the resource expenditure is about an order of magnitude more
than they can tolerate. They simply can't believe it could be
accomplished an order of magnitude more cheaply. I know better.

> Then write some programs to
> do things that will help your support folks and/or developers do a
> better job--for instance, if you store whatever documentation is
> available for each feature in the feature objects you could use
> Allegroserve to provide a web interface for browsing that
> documentation. And if you can gather up the information about what
> customers have what non-core features you can provide another web
> interface for browsing from a particular customer to their associated
> problem reports and from there to the information about the features
> they have.

Good ideas.

> However, you should expect that you're going to have to do a fair bit
> of the grunt work of gathering and entering data, in addition to
> actually writing the tool, in order to get it into a state where it's
> value is obvious to the other folks in your company. And then you may
> only be able to get a few folks, probably some support folks who are
> feeling the most pain under the current (non-) system, interested. So
> make the tool useful for them and they'll start entering data that
> will make the app more valuable. Then you can branch out and add some
> features that make it actually useful for the developers.

Actually, if I can map out a very clear object hierarchy and hand over
a working app, there's a decent chance the CTO would get behind it and
enforce it's use. He's actually a very competent guy (albeit within
the narrow confines of J2EE) who wrote most of the webapp now poised to
take over the market. I might even be able to approach him with just
the object model and convince him to let me work on it on company time.
But I'm not going to do that because of one over-riding fear. Not
that he'd say no. That he'd say yes, but do it in J2EE. ARRRGG. Death
of a thousand small cuts.

> Eventually
> you'll have everyone using it and the CEO will want to claim it was
> his idea all along. But that's okay--you'll know and we'll know where
> it really came from. (And he may try and buy your silence with a nice
> bonus or something.)

Yep, I can see that happening. :)

BTW, I like your book a lot. Haven't bought it yet, but it is
definitely on my list. Chapter 3 alone is worth the price of
admission. It's what finally made me say to myself, "Oh, that's why
they speak of macros with such reverential tones!"

.

Relevant Pages

  • Re: How can I upgrade Office 2002 SP 3 to Office 2007 and keep both versions?
    ... features is confusing and takes up space that I'd rather use as my ... well -- and my issue is that the arrangement of the features gives me grief ... and your existing Office Suite is better than the ... I hate to rag on Office '07, but I've found no good reason to migrate to ...
    (microsoft.public.office.setup)
  • Re: A petition to J3 apropos FORTRANs future
    ... reason was used clear back in the late 70's - when almost no ... trashing the lot and adopting even *worse* features instead ... what are your *specific* recommendations about what ... "dirty features" doesn't address the question. ...
    (comp.lang.fortran)
  • Re: public comment on fortran 2008
    ... The f2003 standard is a failure. ... the features depend on f2003 ones or not. ... The biggest reason was that I had been doing it long ...
    (comp.lang.fortran)
  • Re: Leopard and Resolution Independence
    ... we have *no* reason to think this is not working just fine. ... this feature on the Leopard part of www.apple.com. ... It just seems odd that should be so hard up for sexy features, ... ZFS usage likely was planned and then cut - though *never* officially listed ...
    (comp.sys.mac.advocacy)
  • Re: Is there a BEA Tuxedo equivalence in Java?
    ... features (transaction handling, connection pooling, messaging and O/R ... The failure of EJB is also an argument for not using an J2EE ... understand the flaws in the EJB model, how can we know that they ... performance and quality is better using a J2EE application server? ...
    (comp.object)