HN user
Actually, agile was first invented for writing mission critical enterprise software more effectively - thus the emphasis on test-drive-development and a very tight confirmation loop with the users. The fact that it also works well for web sites is great, of course, but it's not where it started.
Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed.
Tracking progress goes on a Kanban board (or digital equivalent).
When developers pull tasks, their name goes on it. If one dev keeps pulling tasks that don't get done, or take far too long, that becomes obvious to the whole team quite rapidly. That doesn't "disrupt" the team at all.
No, standups should not be for project tracking, it's a quick synch up and opportunity to raise issues. (e.g. My task is blocked until X is done). Then you resolve the blockage outside of the standup, in a longer, deeper discussion with fewer people.
Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time.
The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.
Agile only works for certain kinds of developers. In particular, it works well for people who are team oriented and communicate well, able to talk to the rest of the team to coordinate for at least 10 minutes a day, and responsible enough that they push themselves to deliver and get what they need from the rest of the team. If someone's an introvert who wants to be left alone to code, or to rely on a manager for all discipline, they need to be in a different environment, perhaps an old-school waterfall company where the manager hands out assignments and badgers people until they are done. I've done many agile transformations, and some developers just don't fit in agile, and are perfectly happy in waterfall, and that's fine. Though it might mean needing to find a new job.
The point was that it's lower friction to use the AWS services, and RDS is a great example of this - you can certainly run your own database in EC2, but if you use RDS it's far less work as many things are provided automatically or very easily. Of course, RDS doesn't suit all use cases, but that's true of many AWS services.
That's certainly true. Useful Lambda code (i.e. lots of functions cooperating to do something, likely using a variety of AWS services) can only run in the Lambda context. So it's not appropriate if you need to develop offline.
I am not sure that this would be the case. If all the firmware has to do is process G code, that's oh well understood problem, and runs on Arduino's, and whatever is grilling this printer has to be at least as powerful as we oh well understood problem, and runs on Arduino's, and whatever is grilling this printer has to be at least as powerful as Arduino, and he clearly has four more storage since it can buffer print streams coming across the Internet which is a lot harder then coming in local connection. The only limitation I see is that the device does not have a USB port, which means that even if you're printing off-line you're going through Wi-Fi. If the company went under, I'm wondering if the answer wouldn't be to reverse engineer enough of the server-side to print, and run a copy of that locally, without having to change the printer's firmware.
The things that they show (running a web site with lots of UX, slicing, image processing, materials data, catalog of customizable designs, etc.) fit pretty well into a powerful web site/service with a small CPU in the laser cutter. Adding a powerful CPU, etc, would add to cost and complexity - it is much easier to run a web site than to support thousands,of users' local installs, etc. Though i agree that makes the device dependent on their service, that's becoming a pretty common tradeoff these days.