nodemon is a great tool for use when writing Node.js applications. It is a simple little tool that simply watches for changes in the file system of your project and restarts the Node.js application when a file changes. Of course, there are more options, but that’s the essential idea. Unfortunately, once you launch nodemon it is off and running and the only way to stop it is to brek out of the command shell with
I just read this interview article with Bob Martin and I have a few thoughts about it. Uncle Bob is extremely code-focused and always has been in his career. This isn’t a criticism, far from it, but one must take that into account when reading his opinions on such matters. He is heavily involved in the Software Craftsmanship movement, which he sees as a follow-on to the Agile Manifesto itself. Like any business practice, Agile
One of the most fascinating documents I’ve read to date is the memo from Roger Boisjoly on O-Ring Erosion. The original target audience for this memo he’d written were the management folks of Morton Thiokol back in 1985, about six months before the Challenger disaster. What I find so striking about this whole story is its resemblance to the field of software engineering. We software developers can relate to this story all too well. I’ve
There is a practice in many agile conversations known as having a “Definition of Ready” for a Product Backlog item. That is, a given User Story (or other PBI) must meet the Team’s “Definition of Ready” to be considered actionable or even worthy to estimate. This can be desirable from the team’s perspective when they are not getting enough information about the work they are being asked to do by the Product Owner. While I
I’ve had some great opportunities working with teams applying lean and agile techniques to domains beyond software development. Along with other areas, I’m having lots of conversations around applying Scrum in HR teams. This is fairly unique because the core usage model for Scrum is to apply it when the work is fairly unknown and complex, and the team is working together to create a shared product. Many knowledge worker teams simply aren’t like this.
Several teams I’ve worked with wonder why it is important to finish work within the Sprint timebox. “This is an artificial container for my work,” they explain. “Why can’t our work just take the time it takes? Why must it be get all the way done in one Sprint?” In my experience, these frustrated teams are likely looking to move away from poorly implemented Scrum toward what will be disastrously implemented Kanban and just-in-time work
Many software development teams, especially those creating or supporting a shared platform or infrastructure, find themselves overwhelmed by ad-hoc work requests. A frequent response to this situation is to move from an iterative, incremental practice to Kanban or some other flow-based model. In many situations, this is the exact opposite of what should happen. When a team finds itself foundering under the weight of system support or ad-hoc work requests, it may be time to