Re: Things I Hate (Re: New Website)

From: Robert Ramey (ramey_at_[hidden])
Date: 2024-04-16 17:03:42

On 4/16/24 7:35 AM, Vinnie Falco via Boost wrote:
> Now that we're here I want to tell you about some things I hate. To clear
> out any suspense they are:
> 
> 1. April Fool's
> 2. Deadlines
> 3. New Boost Website
> 
> April Fool's
> 
> I can't stand this fauxliday and I refuse to participate. Every year sees
> the C++ community produce an outsized load of lame jokes. The problem, I
> think, is that comedy on some level has to come at someone else's expense.
> Good comedy at least. Our community is so damn politically correct that
> folks are afraid to make a really good joke for fear of getting canceled at
> some level.

For some reason I don't mind these pranks.  This is kind of weird as It 
seems that I'm disproportionately selected as a target.  Maybe I just 
like the attention.

> 
> Deadlines
> 
> I hate deadlines. People ask me "how long will this take" and honestly I
> have no idea. About a decade ago I stopped trying to estimate how long
> things take as I never was able to give a reasonably accurate answer. I'm
> good at writing the code, but figuring out how long it will take - not so
> much. During development, unanticipated stuff comes up. A discovered design
> flaw or implementation obstacle, which can't be predicted. These days I
> just figure that if a project is properly staffed and there is reasonable
> daily progress, eventually it will get finished.

Dead on here.

I've always worked as a free lancer so this is a really sore point.  The 
main problem is that one cannot know the scope of a job at the beginning 
because 90% of the information required is not acquired until the 
project is mostly "done".  This is cause of failure of the "waterfall" 
method.

Good news is that I've managed to solve it:
a) I make an hourly contract with the customer with only the barest 
verbal indication of might it entail in cost/time.
b) I get a wish list from the customer of what the final end goal is 
supposed to be and a list of features the product is supposed to have in 
order of importance.
c) I keep a timecard with resolution to a minute.  I can check in/out of 
a customer project in under 2 seconds.  So if he calls me for just "one 
question" he gets billed for that and only that.
d) I deliver a goal/accomplishment every week
e) d) above means that I start with something ridiculously simple. 
Maybe only a visual prototype.  Or many a demo of some existing product 
to be integrated.  Something, Anything.
f) The we build on e) above, week by week.
g) We always have something working but never have anything finished.
h) Eventually we have something usable but with missing features.  At 
this point it becomes clear that the original list of features is 
missing some necessary stuff and has a bunch of stuff which is totally 
unnecessary.  A large number of features are pushed to the bottom of the 
list as it becomes apparent that the marketing department added on a 
bunch of useless crap just to show their power.
i) As we work down the list, the product has more stuff.  Also there is 
the timecard hours/cost to consider.  At some point the customer 
decides: it's not worth paying for more features anymore.  The value 
isn't worth the cost.  So the project "ends"

The customer is happy isn't paying for anything that's not adding value. 
He feels as if he is in control. He doesn't feel that he's being rolled 
by some pompous/arrogant narcissists who treat him like an idiot (aka 
software developers).

The product usually doesn't look like what was originally intended. 
Again because we don't know what's its supposed to look like until it's 
done.

Programmers maintain internal and external documentation in parallel 
with feature implementation.  Because:
a) Otherwise it won't get done at all.  Especially if the customer has 
to pay for it at the end as an "extra"
b) Doing the documentation catches many design bugs.  If one can't write 
down what the feature is supposed to do and how it's expected to do it, 
it's likely undoable.  (see Ramey Rule)

Of course their are failed projects. I've had my share The upside is 
that they were misconceived in the first place and failed as soon as 
possible - thus minimizing wasted cost.

> 
> New Boost Website
> 
> Well I don't hate the whole thing but there is definitely stuff which is
> bothering me. Like how long the thing is taking. Seems like it is still not
> ready to go up on boost.org. But more importantly I have to be honest...
> I'm not feeling this Cairo font. I am just going to come out and say it:
> the old Quickbook stylesheets are superior to the new stylesheets which
> render in Cairo. Compare:

I like the idea of updating the boost website.  I don't like the way 
it's been approached.

There is a human bias towards "Lets redo this right".  But that's based 
on the misconception that we all know and agree what "right" is.  The 
boost website has accumulated information in sort of 
haphazard/uncontrolled manner.  That's why it has everything.  Starting 
from scratch isn't going to improve it.

I would suggest a more incremental approach.

See the web site as a frame work for all the stuff that's already in there.

a) outline:
   1) information for users
      1) acquiring libraries
      2) building libraries
      3) testing libraries
      4) addressing problems
   2) boost tools
      1) b2
      2) CMake
      3) BCP
      4) library status
      5) Boost Book
      ...
   3) information for developers
      1) documentation
         1) users
         2) developers/maintainers
      2) dev
      1) compiling
      3) linking or

Or something like this.  This would provide a space for all the current 
pages.  Best of all it, it could be expanded so that space for new pages 
can be provide.  Periodically we could argue about how the index should 
be structured while leaving the specific pages to the individuals that 
have the most interest in them.

Note if we used Boost Book as a basis for making the website, the above 
index/navigator could/would be generated automatically.

This like style sheets are easily changed if we agree by convention to 
all use the boost one.

I'm aware that this is not "modern".  I don't care.  Most "modern" stuff 
sucks.

Robert Ramey