Thoughts, Rants and Arguments: My DevTeach 2007 Rollup

In case you’re wondering why the Shade Tree Developer has been content free the last couple of weeks, I’ve been preparing for the talks that I gave at DevTeach this week.  DevTeach 2007 is now in the books, so I’ll trade in this strange Spoken Word tool for the more familiar Written Word and the wonderful magic of CTRL-Z.  In other words, it’s time to do one big ol’ stream of consciousness post on everything I was thinking about this past week.  I will surely get flamed for a bit of this, so stay tuned.

Enough rambling, here’s what was trickling through my head after last week:

 

Hanging with the Cool Guys

These kinds of conferences are great mostly for the people you meet and interact with, and DevTeach was extraordinary in this regard.  One of the things I miss about Austin is the constant entertainment that Bellware instantly provides in any situation. 

I think I could easily spend all day talking to Jean-Paul.  You should definitely take in his week long .Net training courses if you ever get the chance. 

For months now, I’ve been looking forward to meeting the Israeli contingent, and we’ve even accused Bellware of helping stage the Agile track just to manufacture an opportunity to bring them to North America.  Roy, Udi, and Oren (Ayende) are three of my favorite authors and blogger’s.  Meeting them in person was every bit as cool as I thought it was going to be.  I love Ayende/Oren’s passion and energy for development.  Udi took some time with me to demonstrate his approach to DDD within an SOA.  The dude’s seriously got his head on straight.  I got to take part in great conversations every single day on all things software related, but I think the most memorable episode at DevTeach was talking with Roy Osherove about our experiences being new fathers.

I was on the Microsoft & OSS panel moderated by Ted Neward.  That’s going to be one for the scrapbook (even if we didn’t really get very controversial until the P&P stuff came up).

I also got to hang around a little bit with Rob Daigneau.  Cool guy.

 

Seeing how the other half lives

I worry a little bit sometimes about living in an Agile echo chamber.  I bet better than half of the RSS feeds I subscribe to are from Agile practitioners.  I’m pretty sure that the majority of the people who subscribe to my blog either individually or through the main CodeBetter feed are already pro-Agile to some degree or another.  I used to purposely read Hacknot (dropped because he doesn’t write much and he’s just too curmudgeonly) and Software Reality (dropped because they’re just plain dumb) just to make sure I got a more balanced diet of intellectual content. 

During the last day of DevTeach I purposely went to a talk in the architecture track about building application frameworks.  I knew the talk was going to be far outside the realm of Agile thought, but I love talking software design so it sounded like an interesting talk.  I just wanted to see how the non-Agile guys were approaching design and software construction and see if there is something else I need to be paying attention to. 

From the first slide through the very end I wanted to jump out of my chair and argue with him on almost every single thing he put forward.  The nameless architect (as I will refer to him throughout the rest of the post) lost me immediately.  Let’s see if I can remember all the things that bugged me (the sarcastic language is obviously mine).  Build the application framework upfront.  Divide the team into castes.  The upper caste builds the application framework because they’re more suited for the application design.  The lower caste just can’t be trusted, so we’ll strait jacket them with the application framework to protect them from themselves.  Liberally sprinkle your framework with all the hook methods you think you’ll need later. 

Honestly, I think the code he was showing as a sample had some design flaws.  The code munged a couple concerns into one piece of code (always a big no, no in my book).  He was using hand rolled factory methods and inheritance everywhere.  I challenged him on that asking why he wasn’t favoring composition and using an IoC tool to wire it together.  He didn’t particularly give me much of a response.  I think I could have eliminated a whole bunch of his infrastructure code by merely using an IoC tool, and gotten a heckuva lot more flexibility out of the framework to boot.  More importantly, the code wasn’t testable — and you know for me that testability is an almost mandatory prerequisite for being “good” code.  The maxim “favor composition over inheritance” is probably older than I am, and it’s borne out by my experience.  I’m a little shocked to see an experienced architect so blithely ignoring this advice. 

The end result is that this nameless architect and I could not possibly coexist on the same project.  My longstanding opinion that traditional architects are useless if not downright harmful remains completely intact.  I guess you wouldn’t be slightly surprised to find out this guy is a big proponent of software factories as well.  Of course, this guy had more people in his talks and better evaluations than me, so what do I know?

I’m always hearing that us Agile guys can learn stuff from the older, non-Agile software traditions.  You always have something to learn from more experienced people (note that I did NOT say older), but that particular traditional architect could really stand to spend some time listening to what we Agilists have to say about design and how we work.  The nameless architect was presenting what I would consider to be the best of 90′s era software design, but we’ve learned plenty since then.  The absolute worst part of that talk was looking around and seeing essentially no overlap in faces between the folks coming into the Agile track and the people I saw in the architecture track.  I was horrified at some of the design advice this guy was spitting out, but the other attendees were rapt.  We’ve got a problem there.

 

Software Factories – The CASE Tools Fiasco 2.0?

I’m not old enough to know the details, but I’ve heard plenty of stories about how people invested in CASE tools during the 80′s and early 90′s only to see the movement bomb.  I do think there are some incremental gains to be had from Software Factories (I’m thinking of things like Jay Flower’s CI Factory  and the software factory-like project and code generation in Ruby on Rails).  The problem is that I also think that Software Factories look a heckuva lot like BDUF wrapped up into new, spiffier clothes.  My resistance mostly comes down to three things that I think are going to happen:

  1. People are going to freeze in Analysis Paralysis designing their own software factories outside of any real development work much the same way people waste so much time designing speculative frameworks today
  2. People are going to follow the software factory output no matter what.  Again, this is BDUF at its worst.  Design is never done.  The Software Factory “guidance” and generation may work in most cases for your app, but I promise that there will be more than enough edge cases where the software factory pattern fails.  You better be awake.
  3. People are once again going to waste time creating an environment where bad or mediocre developers can create acceptable software instead of investing in people.

Any older guys out there want to comment on the CASE tools from the 80′s?  I couldn’t find any information on it at all, but I’ve heard plenty of horror stories.

 

By the way, there *IS* a Silver Bullet

After the first day I started to count how many conversations boiled down to an issue of safety versus power.  It came up talking to a Sql Server guru who wanted to do data access through sproc’s just to protect the database against the developers.  It came up several times in discussions about using Aspect Oriented Programming and Metaprogramming.  The nameless architect was trying to design a framework that forced developers into a strait jacket to prevent them from doing something wrong with the obvious implication that the developers just couldn’t be trusted.

It comes down to a choice of:

  1. Enabling developers with the maximum in language and technical power and trusting them to do the right thing
  2. Making development “safe” for lesser skilled developers by taking choices away from developers

I read recently an argument that choice #2 does far more to hamper the efforts of your best developers than it does to make weaker developers more productive.  I agree.  So wrapping this whole stream of dialogue up, I’ll say that there is a silver bullet(s), it’s:

Skill.  Knowledge.  Experience.  Passion.  Discipline.

In other words, it’s the people stupid!  We need to invest much more in our people and the general skill level of the people doing the work instead of wasting so much energy on newer and newer forms of governance.  We pay a very high price in productivity by not doing a better job of creating strong developers.

 

Why can’t you trust your developers?

Since this came up soooo many times, I have to ask — Why can’t you trust your developers to do the right thing?  If you don’t trust the developers, what can you do about it?  The hiring process is an obvious first step, but you’ve largely got the people that you’ve got.  Can you work with them?  Communicate better?  And how do you know that the fault isn’t with you?  What is it that made you trustworthy?  Can it be repeated for another person?  Do you really think you’re that special?

Or is the general population of developers so bad that this is hopeless and we really do need to worry about better and better ways to wring usefulness out of bad developers?  I hope this isn’t true, but it seems to be the prevailing opinion of the majority of people I’ve spoken to in the last year or so.

 

There are no smart guys, there’s only us

When I write blog posts giving any type of advice I’m always waiting for some smarter, wiser developer to set me aside and say, “let a real expert handle this.”  One of the other Agile track speakers said to me that he just doesn’t feel like he’s that great, and he’s always waiting for someone to call him out on that.  A great developer I worked with in the past had a phrase for this feeling:  “There are no smart guys, there’s only us.”  There is no expert on the hill.  No one out there knows everything and has all the answers.  Look, I’m an elitist with a sizable ego, but I know there are plenty of things I don’t know all that well and there are plenty of folks that intimidate me.  You know what though — they’re just guys. 

Not naming any names, but most of you know who I’m talking about, I joined an elite consultancy four years ago thinking that I’d get a chance to learn at the feet of the masters.  I definitely learned a tremendous amount there, but I walked in as a technical lead from day one.  Maybe that sounds strange, but that was a huge disappointment for me.

So what am I saying here?  I guess I’m saying that

    1. No one’s infallible and all knowing
    2. Don’t sell yourself short compared to other people

To take one last shot at Software Factories, if there are no smart guys, why the heck should I trust some guy who doesn’t know me or my app to do my design for me?  I certainly don’t trust that nameless architect to design software, so why the f*^%$ should I take a Software Factory from this guy? 

 

XP environments are so much more fun

I sat in on the lunch time session on Pair Programming from a couple folks from Oxygen Media.  Pairing is good, blah, blah, blah.  What really struck me about their talk was how much I miss working in a dedicated Extreme Programming shop.  I think XP teams and XP environments have far more energy and collaboration than traditional teams.  You can just feel it in the room.  My client environment is pure “cubesville” and the place is just flat out dead — excuse me, professional.  Work is work, but all things being equal I’d rather have an environment that allows me to have fun and be effective.  Then again, being effective is fun to me even without having toys everywhere.

I’ve met 5-6 of the Oxygen Media team now in various events in NYC, and I gotta say that I think it’s ironic that the “O” network, home of countless bad made for TV movies, is also home to such a cool bunch of programmers.

 

Microsoft, OSS, and the Patterns and Practices Team

I’ve said it before, and I’ll say it again now, the negative relationship between OSS efforts and Microsoft proper is an opportunity lost for the .Net community.  Yes, I do think the lawyers are largely to blame for MS’s consistent resistance to open source tooling.  The Java world just uses JUnit & Ant inside of their IDE’s (I’m thinking Eclipse & IntelliJ).  MS has to go and waste the time and energy to recreate NUnit and NAnt — among others.  Those resources really could have been better spent on something else.  But no, because of the constant threat of litigation, MS studiously avoids any relationship with OSS tools that originate from outside Redmond.

A side conversation that I had after the panel is that innovation in the .Net world is almost entirely limited to our one single vendor — Microsoft.  OSS efforts, even when they’re arguably more effective and higher quality, just can’t make any inroads against MS’s official position.  In the OSS panel I brought up the Java community’s far greater efforts in the OSS arena.  Yes, the Java guys have more fragmentation, but they also have far many more choices and innovation comes from the community themselves.  I mentioned to Ted Neward after the panel that I wanted very badly to jump into Ruby development last year when I was changing jobs because the Ruby community just has so much more energy and passion than .Net.  Alas, being a .Net developer just flat out pays too much, and there’s cool stuff coming down the turnpike for us without jumping ship (funny, I wrote this sentence before Hanselman’s report from RailsConf).

Ayende took a shot yesterday at the Patterns and Practices team at Microsoft and the Composite Application Block that I thought was a little bit harsh.  Chris Holmes fired back and called him out it.  Ayende responded.  Udi wrote a very reasoned opinion piece about the same subject called Why I don’t worry about the Patterns and Practices Efforts.  I’m going to come in somewhere between Ayende and Udi.

In our OSS in the Microsoft World panel the P&P team inevitable came up, since their work borders on open source and much of their work directly competes with OSS solutions.  Both Ayende & I made some criticisms of the Patterns and Practices team and their work.  I think the P&P team’s framework products are hampered by the fact that these tools are written in a vacuum outside of any one project or group of projects.  It’s speculative design.  I’m very strongly in the camp that says frameworks should be harvested and grown, not built.  Another thing, it’s hard to create innovative ideas on demand the way P&P probably has to work.  In Mario Cardinal’s session on Test Driven Architecture, he talked about “A ha!” moments where a sudden design realization leads to leaps in design quality.  It’s similar to Eric Evan’s “breakthrough” idea from DDD.  I guess all I’m saying is that the P&P has a very difficult job in some respects.

I kind of wish the P&P team wasn’t necessary, but they are.  Like it or not, they have a vastly more visible pulpit to teach design principles and push better tools than any one of us here in the blogosphere.  I’m not wild about the tools that they produce and I’ve almost completely managed to avoid using them, but their work on explaining the underlying patterns of the tools is far more important than the tools themselves.

I do wish the P&P team would reach out much more to the OSS community.  ObjectBuilder in particular probably could have been a better tool if they’d reached out and asked questions or at least researched existing tools instead of recreating the wheel.  I’d also like to see the P&P team occasionally feature OSS tools.  I.e., if you like ObjectBuilder, try Castle Windsor, StructureMap, Spring.Net, etc.

I’ll leave you with this thought (from me):

The Patterns and Practices team is a little beacon of Agile light in the Microsoft sea.  Yes I don’t think that many of the P&P solutions are really all that great, but I want the P&P team to succeed.  A strong, visible P&P team benefits us greatly.  The P&P team is making it easier for me to use the techniques like Dependency Injection and TDD on client engagements.  That’s a win.

 

You don’t need to take the CAB

I might have helped spawn the Ayende/Chris Holmes thread on the CAB with this bullet point taken from my talk on WinForms design patterns – “Psst. You don’t need the CAB to build large, maintainable WinForms applications.”  I meant that statement very literally, but even if you’re using the CAB it’s important to understand the underlying patterns and concepts first.  I know there was a feeling among many of the Agile track speakers that the core design concepts are far too frequently skipped en route to memorizing the API’s.  You’ll be much more effective with the CAB itself if you understand what the CAB designers were trying to accomplish and why the screen responsibilities are split the way they are.

At the end of this, I just don’t think the CAB holds much value for me.  Granted I haven’t used it in anger, or really studied it all that much.  Part of that is because every time I look at the CAB I see all kinds of unnecessary complexity that results from trying to be so generalized.  Any framework that requires me to wrap my application around the framework has to cross a very high bar of value added to make me use that framework.  I sincerely think that I can accomplish a solid separation of concerns and even pluggability with my own code and an API who’s semantics reflect my application in specific, not a CAB abstraction. 

Chris Holmes asked the rhetorical question “how long would it take to duplicate the CAB yourself?”  The answer is that you don’t.  You grow something during the execution of your user interface features to support your functionality.  If you have a strong understanding of the underlying patterns like Model View Presenter, synchronization options, Application Controller and Application Shell, and Event Aggregator’s, it’s pretty likely that you can build something that works better for your specific application than the one size fits all CAB.  Wiring pluggable UI elements together is relatively simple with the usage of an IoC tool.

And yes Chris, I’d much rather use my own fully-featured StructureMap tool than deal with the very limited ObjectBuilder DI tool embedded inside the CAB.  Guilty as charged.

I thought my WinForms patterns talk went well enough to get reused, but if I get, let’s say 3+ comments asking for it, I’ll convert that content to a set of blog posts along a “Build Your Own Customized CAB in 24 Days” theme to try to prove that building your own MVP infrastructure is a suitable task for mere mortals.  The sample code is mostly written, so it’s not that much work.

 

What’s important?

About midway through DevTeach I realized that I hadn’t managed to attend any of the sessions on newer technology.  I wish I’d managed to get to the WF/WCF/WPF talks, but I’m not too concerned because the content that I saw was very good (and besides, I was heads down doing last minute code samples for my talks).  The talks that I *did* attend were largely on subjects that I think are more core than API’s.  Configuration management, what to test and how, design patterns, design concepts, things that apply to every single project you’ll undertake.  Yes Linq and WCF are sexy, but I bet it won’t improve ROI as much as improving your knowledge of software design in general.

 

C# 2.0 today is starting to feel like VB6 in 2001

In the spring and summer of 2001 I was working on a system that included a configurable workflow engine being coded in VB6.  I pushed VB6 to its very limits trying to make it behave like a fully OOP language.  VB6 felt limiting.  C# came along with full OO and multi-threading.  I felt empowered.  Fast forward to today, and C# 2.0 is feeling limiting to me.  I’m wanting to write more fluent interface code, and C# will do it, but it’s bulky compared to other languages.  I’m wanting more functional language support, but the 2.0 anonymous delegate syntax is far, far too verbose.  I’m finding all kinds of uses for metaprogramming, which is far beyond C#’s abilities.  Ayende mentioned wanting “missing method” type effects in .Net.  It’s time to move on.  C# 3.0, or better yet, IronRuby, just cannot get here fast enough for my taste.  Give me sharp tools thank you, and leave the safety scissors for someone else.

 

Challenging the Notion that Visual Programming is Good

I think the .Net community as a whole has a dangerous set of blinders on when it comes to visual programming.  My nameless architect ended his talk with a quick demonstration of MS’s new tools for defining a DSL modeling language for your tool.  If you haven’t seen it, it gives you a graphical design time tool that allows you to create UML like models that generate code.  He made a whopping assumption that was taken in hook, line, and sinker by the audience — it’s better because it’s graphical.  Is it really?  And compared to what?  For far too long, from Visual Basic, we in the Microsoft camp have worked on the assumption that visual tools and better design time support automatically equates to productivity.  For our own good, we need to collectively challenge this assertion about the supposed superiority of visual programming and learn about code centric techniques that might lead to better productivity and far better maintainability.

 

ThoughtWorks is Busy

From a distance, I’m enthusiastic about some of the things coming out of ThoughtWorks right now as they seem to be reinventing themselves just a little bit (NOT excited enough to even consider going back and traveling every single week though).  While I was at DevTeach I got to see a very brief demonstration of Mingle, the new Agile project management tool from ThoughtWorks Studio.  Jeremy’s in depth review from that 10 minutes — Mingle rocks!  It mimics the Information Radiator motif you get from a physical representation in an electronic form.  I’m using Jira & Confluence at my client, and I’ve used early versions of TargetProcess (for about a week before we blew it off), but Mingle already feels more “right” to me (but I am ex-TW and it’s built for their style of working, so take that with a grain of salt).  

Just as an aside, Mingle is written in Ruby on Rails, but running on JRuby.  Do you remember when .Net was the multi language, single platform virtual machine, and Java was the single language, multi platform vm?  It’s looking more and more like each VM is going into more and more directions.  That can’t help but be better for us all in the long run.

JP gave ThoughtWorks studio a bit of link love too.

 

Entity Framework

I’ll say this very briefly because I’ve already written negatively about the Entity Framework, and nothing substantive has changed since then.  The Entity Framework is clearly a challenged project right now, and it’s obvious that they’re getting pulled in a lot of different directions, most of which I simply don’t care about.  When we went to the EF focus group it was immediately hijacked by the data centric guys as a forum to vent over EF’s support for sprocs.  Since I largely zoned out when they said Stored Procedure, you’ll have to research what they were talking about on your own.  The point being that they aren’t going to be able to make everyone happy, and I think it’s pretty likely that other voices will be much louder than mine when it comes to the feature prioritization of EF.

NHibernate just celebrated a new release.  I’m thinking more and more about how to use iBatis for places where the database either stinks or you need to utilize the database capabilities.  Because of the wonders of OSS, plus some solid commercial tools for persistence as well, I’m just not all that concerned about whether or not the Entity Framework ever ships right now.  Unless a client forces me to use it just because it’s from MS of course, then I’m going to care:(

 

 

Ok that’s enough.  I’m going in to work this morning for the first time in a week.  I’m expecting to be just a little bit buried for awhile.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://twitter.com/jeremydmiller jeremydmiller

    *I* heard it first from a former colleague at ThoughtWorks in ’04. He had enough personality for me to believe that it was from him originally, but beyond that, I don’t know.

  • Eric Nicholson

    Is this really the original source of “There are no smart guys, there’s only us”? I use that phrase all the time. I remember reading this article when it popped up in my feed reader years ago, but I always assumed the quote paraphrased someone like Ben Franklin or Winston Churchill.

  • anshu sharma

    hey anyone expert in java.wanna make him/her my guide to teach me little tit bits .i am not new to java but i am new to industry.wanna learn the ways to think for a solution in software development.my email id is anshusharma11nov@gmail.com
    bye
    waiting for reply

  • http://dotnet.agilekiwi.com John Rusk
  • http://dotnet.agilekiwi.com John Rusk

    Great post. I like your comments about “visual” being incorrectly equated with “better”. I’m particularly interested in how that relates to workflow tools at present, where “executable flowcharts” seem to be the tool of choice. I can only find one justification for that viewpoint – which is that until recently code-based solutions couldn’t support long pauses. But now they can.

  • http://flimflan.com/blog Joshua Flanagan

    “I think the P&P team’s framework products are hampered by the fact that these tools are written in a vacuum outside of any one project or group of projects.”

    I’m not sure this is a valid assumption to make. It may appear that the P&P team is acting in isolation, but I bet the reality is that they are constantly getting feedback and suggestions from Microsoft’s army of salesman, er consultants, in the field.

    In fact, I know the CAB itself grew out of a Microsoft engagement with Dell (among others, I’m sure).
    http://blogs.msdn.com/dphill/archive/2005/05/19/Composite-UI-Application-Block.aspx

    http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=48525

  • varely

    In your search for more functional style language, metaprogramming support and sharpen tools, take a look to Nemerle. For me, it will be next language that i’ll learn.
    From http://www.nemerle.org :
    Nemerle is a high-level statically-typed programming language for the .NET platform. It offers functional, object-oriented and imperative features. It has a simple C#-like syntax and a powerful meta-programming system.

    Features that come from the functional land are variants, pattern matching, type inference and parameter polymorphism (aka generics). The meta-programming system allows great compiler extensibility, embedding domain specific languages, partial evaluation and aspect-oriented programming.

  • http://blog.timok.com Srdjan

    David: -1 for CWAB. Don’t understand the need… Use Monorail.

    Lightweigh WinForms opensource MVP framework would be great. Perfect application that will get Structuremap more widely known…

  • http://www.evanhoff.com/ Evan

    +1 for the CAB posts :-)

  • Garry Shutler

    @Dave Laribee, thanks for the definition and the link.

    I’m around the stage where I’ve read about most concepts utilised in agile development, but can’t quite remember their names so then having to get the names from an acronym is a step too far at the moment!

  • http://vanryswyckjan.blogspot.com/ Jan Van Ryswyck

    “Build Your Own Customized CAB in 24 Days” -> count me in.

  • http://davidhayden.com/blog/dave/ David Hayden

    If you decide to make building the CAB, or better yet, the Composite Web Application Block ( CWAB ), an open source project, I will help.

    I would like to build an open source project for the experience during the evenings while I hang with the kids during summer break.

    The CAB and CWAB share similar functionality and could probably be done concurrently. I can start next week when school is out of session :)

  • chuggle

    Great post – agree wholeheartedly with everything you say…especially about hiding things from developers (I think that says more about the hiring technique of the companies involved)

    I love P&P – not for the code but because MS released something that challenged the way I thought about design (after all if its come from MS it must be correct no? *ahem*)…a quick afternoon on t’internet and I’d compiled a list of new things to study

    Several years later and the list is getting still longer :)

    But if at the very least P&P can fire up disillusioned MS developers like me then they need a hearty thank you from the OSS community

  • Lion

    Add my vote for “Build Your Own Customized CAB in 24 Days”. And I think that makes it at least 4.

  • http://blog.timok.com Srdjan

    Informative and thougthfull post…

    +1 Build Your Own Customized CAB in 24 Days

  • http://laribee.com/blog Dave Laribee

    “Build Your Own Customized CAB in 24 Days” += 1

    @Garry IoC = Inversion of Control

    See: http://www.martinfowler.com/articles/injection.html

  • Garry Shutler

    Pardon me for being a bit noobish when it come to agile/general software architecture TLAs, but what does IoC stand for?

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Everybody: Yes, I’m stupidly long winded — but it was a long week and I wanted the rollup out of my system.

    @Jeffrey: I think I’ve blown my conference wad for the year, and I’m going to try to weasel my way into speaking at DevTeach Vancouver in Nov. You’ll have to party without me.

    @Aaron,

    Nice point. I think the decision is based around whatever choice enables us the most. I really don’t want to code without effective garbage collection on a day to day basis. I’d choose safety in that case because in that case safety == productivity.

    @Fregas — I know, we’ve gone around on this one before. That flexibility has to be purchased by better, more rigorous unit testing. If Anders can deliver more and more metaprogramming in C# 3+ it makes for a better set of choices. I think the refactoring support ala ReSharper will follow in time for Ruby. I’m not all that thrilled about coding without at least Rename refactorings.

  • Aaron Armstrong

    What about managed code? Isn’t this a form of safety over power? You like safety in this case, right?

  • http://www.smips.com Eric Neunaber

    Also, sometimes you use to many acronyms. It is Monday morning and my brain doesn’t think that fast. :-)

  • http://www.smips.com Eric Neunaber

    “For our own good, we need to collectively challenge this assertion about the supposed superiority of visual programming and learn about code centric techniques that might lead to better productivity and far better maintainability.”

    I couldn’t agree with you more on this point!!! The last couple years has been an awakening for me and I try to preach this to others! Just because I’m good with the .net framework, does not mean I’m a good programmer. Great rant.

  • http://www.dotnettricks.com Fregas

    I haven’t finished this Jeremy…its a long article. But i just had to stop halfway down the page and make a comment.

    I hear a lot of developers nowadays talk about “Sharp Tools” and “Trusting the Developer” etc. Often, they will comment that its ok to break encapsulation, abandon strongly typed languages, etc. because these practices allow “more flexibility.”

    There’s a time for everything. Ruby probably does prove that allowing a fully dynamic language makes one a lot more productive in many cases than a language that only allows the same dynanism thru a clunky reflection model (.NET & Java.) I think in some cases, a dynamically typed language makes certain tasks easier than a strongly typed language.

    At the same time though, I’m torn. I really like that when I rename a method, the compiler finds all the places that broke. This typically would not happen with a language like Ruby. I like that if i try to access a private field or method, the compiler screams. This tells me that i’m using something that was not meant for public consumption and that i may be writing code that is becoming strongly coupled with the internals of another class (which is bad still, right?) Rather than being “Straight Jackets”, these limitations help me when my project gets big. Of course, I wish it was easier at times to get around them, but that doesn’t make me want to abandon them entirely. There are many times that .NET”s type system really makes me feel tied down and limit my code reuse, but these are usually the exceptions rather than the rule

    I don’t think these issues are about “Trusting the Developer” per se. I think its just an acceptance of the limitation of the human mind. Structured programming (forget about OO for a second) is based on this. I can declare a variable in an “if” statement or “for” loop that only has scope for that block. The variable goes out of scope after that block. This “straight jacket” is actually very handy, because i can’t keep track of every variable in my head for the entire class. I view things like Encapsulation and Strongly Typedness along the same lines. They structure things so that i don’t paint myself into a corner the way i did in my classic ASP/VBScript and Coldfusion days.

    I agree about BUFD and not building frameworks in advance because “the junior guys can’t be trusted.” I think a team has to work as a team (not hierarchical castes), communication is key, the junior guys have to be trained and mentored, etc. I’m not a big fan of CASE tools or inflexible, dictated designs handed down from on high by supposed “architects.” But unfortunately the Ruby and Agile movements are also pushing boundaries that i think exist for good reason.

  • Mike Pond

    Great post. And I’d also love to see the “Build Your Own Customized CAB in 24 Days” series.

  • http://www.jeffreypalermo.com Jeffrey Palermo

    Ok. Now I’m finished reading this chapter, er, post. :)
    I wish I could have been there. Any chance you’ll make it to Tech Ed? I’m a staffer at Tech Ed working the Architecture and Strategy TLC booth, so perhaps I’ll be able to help out some architects learn to trust their developers.

    I see it all the time, just like you: decisions made BECAUSE someone doesn’t trust someone else. And it seems that it’s unprofessional to address the distrust. Weird.

  • http://www.jeffreypalermo.com Jeffrey Palermo

    Definition (to help others like me)
    curmudgeonly (adjective form of curmudgeon):
    ‘An ill-tempered person full of resentment and stubborn notions.’

  • http://community.hdri.net/blogs/chads_blog cmyers

    At the risk of contributing to the echo chamber and closed-loop back-patting ring, I did want to confirm at least one of your assertions (about big, closed frameworks being the WRONG approach). The last place I worked, before I understood (correctly) TDD, Agile, etc — and I didn’t even KNOW about IoC unfortunately — I built one of those big, hand-holding, protect-users-and-developers-from-themselves frameworks.

    The good news is, in spite of itself it mostly works and solved the immediate problem, but the bad news is bad. It’s impossible to extend very far, it’s difficult to maintain, it’s impossible to test (except for higher-level integration-type tests), and it eventually became a liability to the company, as Bellware can attest.

    So the lesson I learned is that just solving the immediate business problem is not always the correct answer. The immediate business problem seems the most important at the time, but there are longer-term and more pressing and important problems that need to be addressed that many people (myself included) never think about.

    Opening up the frameworks to allow for IoC and replace-just-about-anything-from-the-middle-out allows for near limitless flexibility, not to mention increasing your maintainability and testability (thus saving time and money in the long run).

  • Mark Holtman

    Consider this one of your +3 comments requesting your WinForms talk be converted to some blog posts.

    (I’d leave two more comments if I didn’t consider it cheating ;)