Skip to content

Bio

When I was growing up in a farm community in Missouri, there was a “special” breed of folks around called Shade Tree Mechanics. Usually they were not the most reputable people in the world, but they had a knack for fixing mechanical problems and a reckless fearlessness to tinker with anything. A shade tree mechanic can be spotted by finding the pair of legs sticking out from under a beater car on blocks, surrounded by other skeletal vehicles crowding the rest of his scrubby, junk-laden yard. The beaters you see abandoned all around him aren’t useless, they’re fodder. He takes bits and pieces and tweaks and tunes, and comes up with a creative solution to your needs. Reputation notwithstanding, a shade tree mechanic knows how to get things running. While I don’t have any particular mechanical ability (despite a degree in mechanical engineering), I like to think that I am the developer equivalent of a shade tree mechanic . My hard drive is certainly littered with the detritus of abandoned open source projects. I’ve had a varied path into and through the land of software development …

  • Shadow IT – Getting my feet wet writing rogue applications for my engineering team. Having a blast cowboy-coding and generating a lot of fodder for the DailyWTF. Oracle, ASP, VB, and DHTML. I moved on to be a “real” developer.
  • Captive IT – Working in in-house IT for a Fortune 100 company designing enterprise applications. I actually got to be the technical lead and architect on a mission-critical system for my first real development project. No prior experience, no adult supervision, no problems. I described the architecture to a former colleague, and his only comment was, “You’re going to spend some time in Purgatory for that one…” I also got to experience my first Death March Project, a lot of corporate politics, and secretive reorganizations. On the positive side, I learned about high availability, disaster recovery, and instrumentation, and I began to successfully apply OO design patterns and UML modeling. Our waterfall process changed often, and was enforced capriciously by a dizzying array of compliance bodies, laying in wait like 18th century highwaymen determined to ambush hapless travelers.  I didn’t particularly like it.
  • Non-Coding Architect – The last reorganization left me a non-coding architect just as the Microsoft world was dumping the DLL Hell (think VB/COM/ASP) technologies for .NET. I got to sharpen my Powerpoint skills while decorating my cubicle walls with Dilbert cartoons. The organization simply could not resist any type of evil fad — CMM, Six Sigma, “It’s not a process, it’s a framework,” fuzzy-headed SOA strategies, offshoring, “programmers are a commodity,” “Who Moved My Cheese?”, the “Fish” book, and a matrix model (yay for dotted-line bosses). I made a half-hearted, quixotic attempt to introduce iterative and incremental processes, but no one in management cared. In order to regain some type of technical relevancy and avoid 80-some hours of mandatory CMM training, I jumped again to become a consultant.
  • High Priests of Agile – I spent a mostly positive year and a half working in the .NET practice for an elite consulting company. Extreme Programming, Test Driven Development, Continuous Integration and .NET. Consulting is a great experience. The intellectual opportunities are abundant, and no matter how bad an assignment or client is, you can solace yourself that it’s only a matter of time before you’ll get to move on to a new venue. I had to learn software design all over again to incorporate TDD techniques. Besides too much StarBucks on the expense account, I got an absolute bellyful of XP theory and zealotry. If I hear, “In the white book, Kent Beck says …” one more time, I’m going to puke. XP, and agile in general, works — but software was written successfully before XP, and some of the older stuff (UML, Responsibility-Driven Design, Design Patterns) is more effective in certain situations. Besides, constant travel with an infant at home is a non-starter, so I left for a job close to home.
  • ALT.NET Celebrity Programmer — After I left the High Priests I thought I knew some things that would be helpful to other developers if only they knew those same things.  I started a blog and wrote a lot.  I wrote about process, design, testing, and even team mechanics.  I jumped into the ALT.NET movement with both feet.  I got a recurring column in MSDN, spoke at conferences, and landed a book deal (don’t go looking for it, I never finished).   It’s been mostly good, but I’d urge some caution for anyone who wants to pursue that kind of thing.
  • Open Source Developer — I’m also the founder and de facto technical leader of the Fubu family of projects and StructureMap.  At any one time I’m more or less feeling guilty because of the issues I haven’t fixed, the adequate documentation I haven’t written, and questions on user lists that haven’t been answered.

My name is Jeremy Miller and I am a Developer and Software Architect in Austin, TX.

13 Comments
  1. Yves Courbier permalink

    Jeremy,

    Thanks for StructureMap. It is a great product.

    I have been using it for some time very succesfully with a config file where the pluginTypes and pluggedTypes are nicely organized. Of course, the assemblies that contain the concrete types are NOT referenced in the calling assembly.

    I am trying to use the concept of Registry DSL instead but there is something that I don’t seem to comprehend when using the For.Use(). In order for this to work, the concrete types MUST be in a referenced assembly but …. this really kills the purpose of IoC as far as I am concerned because the calling assemlby should NOT have any knowledge of the concrete assy, just the interfaces.

    I tried to use the Scan with Assembly and AddAllTypesOf. This resolve my problem but it does not allow passing any constructor parms like the For.Use does and so I cannot pursue this avenue.

    Am I missing the obvious? Should the Registry be in its own assembly that references both the interfaces assy and the concrete types assy?

    Thanks, Yves

    • @Yves,

      Let me get a blog post together for you by the end of the weekend.

      “Should the Registry be in its own assembly that references both the interfaces assy and the concrete types assy?”

      Yes, that’s one way to go about it. The Scan() business can be used (don’t have the code open, so the call might not be exactly right) like so:

      Scan(x => {
      // specify how you wanna suck in all the other assemblies
      x.LookForRegistries(); // this will make it use any Registry classes it finds in the other assemblies

      });

      No xml necessary.

      • Yves Courbier permalink

        Wow, thanks for your quick reply, I appreciate it. I’ll be looking for your blog but I thought I would mention that I did try to put a Registry in the assy that contains the concrete types (which I don’t like to do because I then needed a reference to StructureMap) and use LookForRegistries() but it didn’t work for me:

        Scan(cfg =>
        {
        cfg.Assembly(dal);
        cfg.LookForRegistries();
        });

        whereas this works:

        Scan(cfg =>
        {
        cfg.Assembly(dal); cfg.AddAllTypesOf();
        });

        dal is const with assy name. No need to reply here if you’re going to do a blog as I have already cluttered your BIO page enough ;).

  2. Really enjoyed your article on design patterns for object persistence, it supported the approach I have been advocating for many years with respect to persistence being decoupled from the business objects.

    Just wondered how you reconciled implementing the patterns when using TDD to deliver specific features, we have a similar dilemma at the moment as we are building an application which allows our users to send emergency messages to recipients but the simplest thing to do is to build the vertical slice which simply has a client communicate directly to our message service via a rest api…but I know in the back of my head that using a Message Q to decouple the client from the service will make a lot of sense but I am holding off implementing one until/if we start to see performance/scalability issues, appreciate your thoughts on this

    Kevin

  3. Cerx permalink

    Spent most of the morning reading everything you’ve ever posted about TDD so I can come up with training for my company. It shouldn’t matter, but finding out you’re a fan of the WoT series and the KC Chiefs has made you more of an expert in my mind.

  4. Dan Austin permalink

    Hi Jeremy,

    Not meaning to be contrarian here, but when you write “If I hear, ‘In the white book, Kent Beck says …’ one more time, I’m going to puke,” that’s the very same reaction I get with anything related to Martin Fowler worship. I think there’s a reason Fowler hasn’t updated his brain droppings on GUI patterns since 2006, and that’s because it’s all a steaming kettle of horse doo-doo. Frankly if I ever bother to start a blog, the first (and perhaps only) entry will be Martin Fowler Must Die. I have to wonder how many other people have caused developers to waste so much time trying to measure their private parts against what self-annointed thought leaders like Fowler come up with. Honestly, if you need to write a test to show that three buttons on your Winforms UI get disabled when you do something, maybe you should be in finance instead of software. It doesn’t take a lot of mental juggling to verify that and move on to things worth doing automated testing on. Just sayin’.

    There is no perfect one-size-fits-all pattern, and the use of any pattern puts you in the red and must somewhere put you further in the black than you would have been without it to justify its cost. I haven’t seen a single study that actually quantifies and justifies any of this jumping through your a** to get “fewer UI bugs” compared to just testing what is easily testable. Some things are worth mocking and some things simply aren’t, and there is an optimization curve in terms of getting a project done and done well. When you spend huge amounts of time trying to separate every possible bit of UI, then you are no longer at the peak of the curve and are simply a can’t-see-the-forest-for-the-trees follower of one of many cult leaders in the industry.

    • I’m approving the comment ’cause it’s not crime to be contrarian, but I disagree with everything you wrote besides the meaningless “There is no perfect one-size-fits-all pattern.” As with all design patterns, you have to pay attention to the “why and when is this applicable” and not just blindly follow the mechanics. My experience with the design patterns you’re poo-poo’ing has been positive. Testing trivial code still pays off from the specification and regression test angle. And besides, I’ve seen far too much pain caused by crappy monolithic code in the UI or otherwise to have too much sympathy for the “get r’ done” mentality.

      And for the sake of transparency, I was going to take over the book on Martin’s UI patterns with my own “build your own CAB” writing before I wussed out just to have a life;)

  5. danaustin2 permalink

    Hi Jeremy,

    I respect the fact that you approved the comment. ;) I do want to clarify though that I’m not endorsing a monolithic UI or a “get ‘er done” hacking mentality. I see people on StackOverflow agonizing over what Fowlerism to crowbar into their project and beating their heads against a wall, and while your CAB articles are a really good explication of the concepts, I think devs are in effect browbeaten that these things are “the right way” and that they suck as developers if they can’t wax philosophic on these patterns. We have enough to do to keep up on technology without chasing the thought gurus. If you need trivial UI tests to document your specs, there’s something wrong with your spec process. It might be a nice form of extra documentation, but the real question is how much extra time did it take you to get there, how much extra time does it take to modify something simple in the UI, etc. The real cost tradeoffs are never actually quantified. There is a point of diminishing returns with this stuff, and while guys like Jeff Atwood mention it here and there, it just doesn’t get said enough, and it can come across as yet another coding religious viewpoint. There is a balance in all things, in other words.

    • I’m still disagreeing with you Dan. If we throw out anything as invalid that we’ve seen used badly by the “other guys,” there’d be absolutely nothing left in our toolboxes with which to write software. After having worked with so many developers that don’t think about what they’re doing, I’d rather have the guys who err a bit on the side of agonizing over how to do things. As to your feelings about the testing, I simply disagree. My experience is that all those “Fowler-isms” have led to clean code and fewer bugs.

      “If you need trivial UI tests to document your specs, there’s something wrong with your spec process.”

      That’s a bit near sighted in my opinion. I’d far rather have executable specs than a useless Word document on any given day.

      And it’s a moot point, the second that you use the word “religious” (or dogmatic or cargo cult or whatever) in a technical debate, you automatically lose the argument.

  6. danaustin2 permalink

    Well, hang on here. You used the phraseology of puking if you hear about the white book any more, but I can’t have the same feeling about Fowler? You called yourself a “Fowlbot” in your CAB series, and I automatically “lose” by observing such deference? ;)

    I agree with you that people *should* think about these things, and it’s a strawman to suggest otherwise. I obviously do, or I wouldn’t be reading your CAB articles and the like. I also take you at your word that these practices have lead to “fewer bugs”…but at what cost in time and effort? How long did it take, and what was the opportunity cost of spending that time on more inherently testable parts of the codebase? I’m sure you liked the result, but if you have any links to actual studies, I’m all ears. All I can find are studies where people “like” MVC, and the only balancing comments are the observation that it might not be worth the additional startup complexity for smaller projects — and that’s talking about web projects, where it makes a lot more sense. I can find absolutely nothing that is remotely quantitative in terms of hours spent, number of bugs, time to patch, etc. Anecdotal reports of people who get excited about patterns really doesn’t cut it in terms of the bottom line to the business.

    Now, I deal with horrible legacy code routinely, where it seems half the app is in the code behind for a button click. I’m not remotely suggesting that’s OK, and I have a big refactoring job ahead. The current project uses a third-party Winforms calendar control that likes to be databound to a dataset or POCO collection. So Supervising Controller sounds like a likely fit, yes? A new requirement is that you can click on an appointment, and up pops a complex chart (another 3rd-party databound control) with various data from the database, and if you click on an element in *that* chart, then you get another drill-down chart with different graphical information from related data in the database.

    Using dependency injection I can test that fake data produces the chart *series* I want, but am I seriously going to create individual views and presenters for those drill-down charts? And even if I did, I risk the customer deciding they want a different chart type with different behavior, and then a good chunk of my “investment” in clean separation is wasted. The bottom line is I suspect that for any real-world Winforms app of any complexity, it simply costs more time and effort than it will ultimately save. Since many of these decisions as to the degree of separation are arbitrary, any new developers on the project have to spend a lot of time ramping up on my pet way of doing what I consider clean and beautiful as opposed to applying a KISS standard that tries to find the best mix of minimizing complexity while maximizing testability.

    So I agree with you in the sense that these are tools, and it’s up to the wielder to judge the right tool for the job…I just am of the opinion that going whole-hog with MVC-type patterns for Winforms in general is trying to cram the elegant theory of the square peg into the reality of the round hole.

Trackbacks & Pingbacks

  1. Five Blogs – 24 October 2012 « 5blogs
  2. A Software Developer’s Reading List | Steve Wedig's Notes

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 36 other followers

%d bloggers like this: