A Rant on Professionalism

This is a rant. I’m stating it up front. You have been warned :)  Leave a comment if you disagree, but if it’s more than a paragraph or two, please post your response on your own blog and let us know in a comment.

Currently, on the ALT.NET mailing list, there is a still-active thread about Lean Manufacturing concepts applied in software (collectively known as ‘lean software’ or ‘lean software development’).  Many of the posters are making half-joking remarks, some are serious. I can’t help but get the feeling, though, that many think that Lean software is yet another soon-to-be-failed attempt at the unattainable unified theory of software development processes.  Perhaps it is, but that’s not the point.  The point is that Agile started us on a path to break out of the classic, failed approaches to software development. It helped us realize that there might be a better way and that we have to go find it.

Whether Agile or Lean ultimately fail to become the One, True, and Holy Software Development Process or not is irrelevant. What really matters is that people are trying to find a path to a process that is uniquely fit for software development – as opposed to just using poor analogies in other areas and awkwardly adapting them to software development.  Of course Lean is used for manufacturing and is one of those analogies, so it predictably doesn’t fit with software directly. It is, perhaps, the closest fit we’ve yet seen and so, I hope, produce major strides in the advancement of software development process engineering.  Each iteration of these advancements brings us closer to understanding the nature and complexity of the software development process problem and will eventually lead us to practices and processes which are uniquely tailored and designed for software development and which will produce much greater chances of success on projects.

Unfortunately, cynicism has leaked in due to so many failures from the start and professionals seem to be less and less willing to even consider new ideas because they’ve been so burned by them in the past. I believe a large part of our problems are due to this cynicism. We don’t accept new ideas because, for so long, almost every new idea was crap and would hose us in the end on our projects.  Managers and stakeholders no longer trust us because we don’t seem to understand or appreciate their concerns and seem to only be concerned with technological problems and the latest-greatest tool from [some vendor, doesn't matter].

It’s easy to point the finger at Microsoft and blame them, since many of the tools and the heartache was caused by them, but they were no further along than anyone else. At any rate, we shouldn’t expect a particular vendor, especially a tooling vendor, to champion the cause of professionalism in our line of work. Microsoft will do what Microsoft does and if we demand something from them, they will respond in kind. The real problem is we’re not demanding these things from them (or at least, we haven’t until just recently).  To be clear:

We must take responsibility for improving the state of affairs in our profession and stop expecting Microsoft to do it for us.

And, if you look, ALT.NET has somewhat been demanding higher levels of professionalism and engineering from Microsoft and they have responded. They haven’t radically transformed, nor will they for quite some time because a.) we are in the minority and still a very tiny voice and b.) it’s a large organization and it will take time to turn the giant ship around.  In the end, though, so what?  Software development happened before Microsoft, and it will happen after Microsoft is gone.  What then?  It’s very comfortable to point to the big guy and expect him to solve all your problems, while we continue creating them.

In conclusion, I believe that the state of professionalism in our trade is sorely lacking. It’s not because there aren’t good people, it’s because we essentially don’t have a Scientific Method by which to gauge our success. It’s still so much magic and hocus-pocus.  Consequently, we are generally seen as charlatans and tricksters.  We have very little credibility because of this. To earn trust, we must be trustworthy.  How are we to be trustworthy? What steps must we take as a profession to establish our trust and by what means will we ensure that future generations of our profession adhere to the same level of dedication and professionalism?

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in professionalism, rant. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • David

    I think that part of the problem with the view that we are not professional comes from using terms such as “architect” to discribe what we do. This profession is very new (only about 40 years old) but we are using a term that implies 100′s if not 1000′s of years of growth and refinement.

    Of course the field is not to the level of expertise that we, and our customers, would like. I feel that we need to remind ourselves and our customers that we are attempting to get the skills needed to be professional. The fact is that we have not gotten there yet. And untill we do, we will have problems. We are attempting to find out how, as a profession, to be professionals.


  • Great post, Chad.

    I think another key to the lack of professionalism is that our industry as a whole is horrible at transferring knowledge to new programmers. It seems like an endless cycle of repeated mistakes instead of a solid foundation that keeps growing.

  • Ian Chamberlain

    Understand the sentiment but disagee with the rant. See http://systemfutures.spaces.live.com/blog/cns!AD5058A4F6569231!238.entry.

  • Olof Bjarnason

    I can see a future of software practices leaning (no pun intenden) towards traditional craftsmen like smiths, tailors or wood workers. In those “traditional” occupations, one does not jump into heavy-duty professionalism directly out-of-school. One follows a “master smith” whom you follow as his/her apprentice, maybe for years. That way principles and patterns are learnt much more efficiently than for every single one of us to wade through the same old mistakes.

  • I like your ‘rant’ against the one, true and holy software development process :). I’m with you on trying out things, borrowing inspiration from elsewhere and seeing our practice improve with each iteration.

    A lot of the misunderstandings about Lean Software Development come, as you hint, from people railing against comparing Lean SD to Lean Manufacturing. Most fail to look at existing literature on Lean Product Development (e.g. the stories on product development in ‘The Toyota Way’ or Michael Kennedy’s ‘Lean Product Development’).

    I’m also (somewhat) inspired by the craftsmanship idea (it is more or less suitable, depending on the context). Even here there’s similiarities with lean Reading about how long it takes to become a ‘chief engineer’ at toyota, sounds very similar to how long it takes to become a master craftsman.

    In the end, these are sources for inspiration. Software Development is like… Software Development.

  • Robert Stackhouse

    I think the places that the reputation of programmers as a lot gets burned are 1) the promises we make and 2) our seeming inability to manage expectations.

    I think we try to make to much out of our estimates on projects in knowledge spaces that are completely new to us. In such a predicament, we ought to say our estimates are +/- closer to 100% rather than say 50% (a number I hear thrown out a lot) for the life of the project.

    I think our reputation is damaged a great deal by over ambitious junior or novice programmers working alone trying to make their mark. They either over-promise and over deliver, or deliver a bunch of unusable crap. It takes a lot of knowledge and experience to be a good soloist and newbs just don’t get that.

    I also think that a lot of programmers grew up wanting to be Superman and therefore don’t like telling people things like, “That can’t be done in your time frame.” So our desire to save the day keeps us from being objective as we should be when the stakeholders feel they are in a jam or when discussing new features.

    I also think that Brian’s comment is valid. The knowledge transfer to the younger programmer’s isn’t there. This is for two reasons 1) older programmers want to hang on to their ‘job security’ (please, as if classic ASP voodoo equals job security) or don’t see the value in educating the newcomers and 2) newb programmers think the older guys are out-dated and therefore don’t have anything worthwhile to pass along (there are of course exceptions to both cases, but not enough).

  • +1 for what Olaf said. If we had better training, better education, and a higher barrier of entry to the profession I think we may have better results.

    I don’t think that Agile or Lean or even waterfall are the problem. A bad developer will do a really good job of screwing up a project regardless of the process. Unfortunately the process frequently gets blamed for the mistakes of bad developers.

  • I could not agree more with what Brian Mavity said.

  • In response to what Brian Mavity said, the issue with knowledge transfer is that by the time someone knows enough to become an ‘expert’ on a particular technology, the industry has moved onto the ‘next big thing’ leaving a shambles of half-implemented systems behind.