|
|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk