You haven't highlighted any problem with Agile the methodology. You have only highlighted problems with the skills of your team, or at worst, how your team implements Agile. I don't disagree that having a thought-out event lifecycle approach isn't important, and I'd argue that it should have it's own story. Architecture is important, and sometimes the work these doesn't lend itself to someting traditionaly seen as a task. Architecture is more implicit in the code than explicit lines of code, but it still requires attention. 
The reason I'm so far behind on this list is that once again I've been called into an Agile shop to work on a project which is currently a train wreck and I'm spending 7 days per week trying to drag it out of the path of the impending plane crash before both roll down the hill into a pre-school. Agile is _completely_ to blame for the state of this project. You cannot hope to start a successful project which involves both a messaging system to external devices AND a database without first writing and vetting the following:

When you work off nothing but stories you are hacking on the fly and if your coders aren't system architect level people, not just one, but each and every one of them, you end in failure. You end up with a developer choosing to store data in JSON files for a device taking dozens, some times hundreds of readings per second, appending the new reading to the end of a JSON array and writing the entire file back to an SD card. Without the event->message->device  response->message->event life cycle completely mapped out in a solid document you end up with a dozen programmers working from a dozen different stories doing it a dozen different ways so eventually you end up with an embedded system slamming hundreds of requests onto a message bus for data it only needed to get once at startup.
Interest mailing list

Reply via email to