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