+972 52-548-6969
Redefining reality
The "Tools For Mort" post from Nick Malik had me check outside to verify that the skies are still blue.
Nick seems to define a Mort as:
Mort works in a small to medium sized company, as a guy who uses the tools at hand to solve problems. If the business needs some data managed, he whips up an Access database with a few reports and hands it to the three users who need the data. He can write Excel macros and he's probably found in the late afternoons on Friday updating the company's one web site using Frontpage.
Mort is a practical guy. He doesn't believe in really heavy processes. He gets a request, and he does the work.
So far, he is following the same well known path of describing Mort. The problem is that he then seems to decide that Mort is a super agile guy. Take a look at Sam Gentile's comment:
MSFT is making tools for Morts (the priority) at the expense of every other user (especially Enterprise Developers and Architects). They have nothing for TDD. And I would further contend that making these tools "dumbed down" has significantly contributed to why Morts are Morts in the first place and why they are kept there.
And Nick's response:
Wow, Sam. I didn't know you had so much animosity for the Agile community! Are you sure that's what you intended to say?
Do you really mean that Microsoft should make a priority of serving top-down project managers who believe in BDUF by including big modeling tools in Visual Studio, because the MDD people are more uber-geeky than most of us will ever be? I hate to point this out, Sam, but Alpha Geeks are not the ones using TDD. It's the Morts of the programming world. Alpha geeks are using Domain Specific Languages.
I really have no idea how to respond to such a claim. It certainly doesn't match my experience.
Comments
Thank you. I have no idea what he was talking about and my comments don't show up there
Hi Sam,
Your comments are there now, along with some responses. I always prescreen the comments that come in to my blog because I get SO MUCH comment spam.
--- Nick
this is a nice WTF moment for me...
I always thought the alpha geeks were the ones using TDD, DDD, agile and generaly alt.net stuff. And the morts were doing BDUF and waterfall with all the best microsoft tools they could get.
I'm trying hard to lose my mort status by reading your blog and heading into uncharted territories (uncharted by microsoft that is) and doing all those things people in the smalltalk community have been doing for years and just when i'm getting close someone decides i'm mort again...
I am Hugo:
http://codebetter.com/blogs/scott.bellware/archive/2006/02/08/137715.aspx
I am Hugo too. None of the DevDiv archetypes represent me at all but Hugo does.
I think the entire concept of "Alpha geek" is not used in it's original meaning:
http://dotmad.blogspot.com/2007/06/alpha-geeks-and-morts.html
What I miss a bit is why TDD is in the same scope as DSLs... DSLs often solve a slightly different problem than TDD does, or better: they're used to solve more problems than TDD does.
I have to agree that MS should do more in the TDD / agile department: they're now IMHO too much focussed on the drag/drop programming RAD-oholics of this world.
However, that's not to say that TDD/Agile is how every software application should be written: in a lot of applications, TDD is simply not useful.
Food for another discussion: 90+% of the time/money today spend on an application from birth to death is spend on maintenance. What I'd like to see is how the TDD/Agile movement addresses the problem of maintenance. The main issue is that because a version is already out there, refactoring the crap out of an existing codebase isn't going to be possible, so how is TDD holding up in that kind of environments? Is it then really the silver bullet everyone should be using? I mean: after 2 years in production, no-one ever remembers the post-it notes on the board when the app was made.
Not that RAD-oholics with their mouse-movements are in a better position though, far from it.
Frans, the answer is yes.
If you built it using TDD it will be easy to "refactor the crap out of it" as long as the edges stays the same and the behaviour does to. Here is where IoC and interface based programming really excels.
For chunks of legacy data where no tests have been don before, it is really vital that you wire up some tests that will ensure the behaviour of the current code base before doing any refactoring or changes. Robert Martin describes that process in "Working effectively with Legacy Code" (http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052)
No! I Am HUGO!
(sorry it just seemed a little Spartacus like!)
(no, really, Hugo is spot on)
Comment preview