Personally, I have used nullmailer in the past to provide a sendmail compatible local install that immediately forwards email to the SMTP server of my choice. Has worked flawlessly.
Obviously, that doesn't come with HTML form support, but then I am also not sure I would like the same binary to handle both a HTTP(S) endpoint and email submission :)
> how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values
> If it solves concurrency the "right way" due to supervision trees, why not use Python libraries that also implement the actor model, making Python code concurrent the "right way"?
I can't speak too much about Python – but immutable vars is a core prerequisite for many of the features OTP (the platform underpinning Elixir (and Erlang)).
"Adding manpower to a late software project makes it later" is not hat I even want to argue about. Discovering that a project might run late, and then doing the right thing about that is.. but how is one doing "the right thing" if developers don't want to communicate estimates vs. reality?
"For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects.." (exactly, I made that point as well) "..especially the kind with changing requirements, new issues discovered en route, etc (which is most of them)." If you are working in an environment where shipping something at some random point in the future is fine, well, good for you. The rest of us doesn't work in that world, which means that if you start a large project, lets say over the scale of 1 year, you cannot not talk about progress during that year. This is the point that I want to make.
In that sense: "5 hours spent on X" means, dishonesty aside, that 5 hours have been spent. This has some meaning, namely:
- a) if the estimate has been 1 hour, and this doesn't cancel out over time there is a systemic problem which puts the entire estimate to question. So someone should do something about that, and, whatever that something is - adding new or different resources, changing the goal, changing the timeline, whatever), it is usually not something that developers could do. (Not that I think 5 hours is a useful estimate size for any feature; 1 week, on the other hand, for a set of features would probably be useful)
- and b) if you figure out that team members are frequently spending more than 8 hours per day for whatever features (adjust 8 hours to whatever the team agrees upon) then the team is overloaded, the workload is not sustainable, and, again someone should do something about that...
Really, it shouldn't come as a surprise that - opposite to developers' lore - managers really do add value, especially when they are good managers.
A manager must be able to answer the question "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it. If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable.
If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now.
Time tracking can be a surveilling tool, but it can also be a tool to improve things - someone could find out that a team is running over capacity, and consequently assign more resources to the task at hand or redefine the task.
And, well, for morning standups: when done right they are a valuable tool for efficient communication, and probably better than having people chasing each other for hours on end. IMHO an organisation should agree on a communication strategy that is the most efficient and helpful for it. It is not a religious belief that a standup meeting must be done first thing in the morning, I think that tends to conflict w/the teams personal schedules the least.
Personally, I have used nullmailer in the past to provide a sendmail compatible local install that immediately forwards email to the SMTP server of my choice. Has worked flawlessly.
Obviously, that doesn't come with HTML form support, but then I am also not sure I would like the same binary to handle both a HTTP(S) endpoint and email submission :)