Everywhere I've worked has been in reactive mode. We never have time to slow down and adjust. Never given any time to work on the infrastructure projects that will give us the tools to do our jobs better in the long run.<p>This looks like the epitome of reactionary development. Plus it doesn't lend you any real insight into the "why" of a given problem.<p>In the included example, latency is up on a given method. Lets say it turns out that particular process calls three different "manager" classes, and has another inline sql query. So, you do the right thing and spend a bunch of time cleaning it up and getting things looking more <i>right</i> (with no help from MDD, since there's nothing about development practices in this outline.)<p>Turns out, it wasn't the code after all. Someone had designed autocomplete to work off of a sql table, and someone else disabled the job that re-indexed the search column.<p>* Long story short, TDD and BDD give us development tools<p>* MDD appears to give us... help making minor decisions on potential focus areas? Maybe ammunition to tell our PMs what we should work on?<p>Anyone else see what the big draw for this would be?
Every time I read one of these utopian posts I think of the fortune 50 company I work for and laugh for about ten minutes. I'd rather read a post on bullshit-driven-development.
Deming actually wrote the opposite in The New Economics.<p><a href="https://blog.deming.org/2015/08/myth-if-you-cant-measure-it-you-cant-manage-it/" rel="nofollow">https://blog.deming.org/2015/08/myth-if-you-cant-measure-it-...</a>
Oh my. We need more common sense development practices bundled as new idea. Reminds me of the old saying "If you want to be a guru read some 20 year old papers and republish them as novelty.".<p>This probably works for systems where it's easy to have meaningful metrics. There are plenty of scenarios where metrics are not that easy unless you come up with some bullshit metrics.
Similar to what I am reading in Eric Ries' "The Lean Startup". As Ries points out, you have to be careful which metrics are driving development. Only watch metrics that can deliver meaningful insight to help make good business decisions.<p>Has the "Build, Measure, Learn" development cycle fallen out of favour? Or perhaps, it just applies to a subset of business models.
I am curious how a framework like this would detect and handle something like a pivot. It does seem like the logical conclusion of the agile-mentalities that have been developing and the iteration logic embodied in Boyd's Law (which is, of course, cited). But I've watched several software projects with a lot of promise iterate themselves into evolutionary dead-ends by paying attention to nothing other than metrics, and rapidly founding themselves oscillating in a local maximum.<p>Granted, that may just be my bias towards some manner of top-down vision/guidance speaking. It may be that the global maximum I was imagining never actually existed.<p>I do like the emphasis on single point of truth when it comes to metrics. I think that idea is integral to any software development process that wants to have a bus factor > 1
Here's a similar post that I thought was quite good:<p>"If the system is not easy to monitor, it is not well designed"<p><a href="http://benjiweber.co.uk/blog/2015/03/02/monitoring-check-smells/" rel="nofollow">http://benjiweber.co.uk/blog/2015/03/02/monitoring-check-sme...</a>
isn't this just a tldr; of Lean UX? <a href="http://shop.oreilly.com/product/0636920021827.do" rel="nofollow">http://shop.oreilly.com/product/0636920021827.do</a>