Agilist in the Trenches

If we sit back for a minute and think about the purpose of a shared workspace the reason is to improve communications and accountability. However, there are many other ways to improve communications: traditional methods such as phone, email, training, meetings, more documentation, and team building; and newer methods such as collaborative websites (wiki/sharepoint), instant message, mobile communications (email, IM), etc. The beauty of a shared workspace on accountability is that unlike most other accountability techniques, the people involved generally do not notice the imposed burden.

More accountability usually has a positive effect on productivity but also increases the turnover rate. More communications usually has a positive effect on productivity when people get to see more of the whole picture and when it helps to correct problems early in the process (this is the biggest win). However, communications can become cumbersome as easily evidenced by anyone experienced lots of meetings.

There are many different work styles and a shared workspace will be very welcome by the most sociable and those who like the discipline it enforces, but the more independent, well-disciplined, or well-organized will generally resent the environment. Hopefully, your hiring process finds you top talent who are organized, disciplined, and great communicators, in which case I wouldn’t go to a shared workspace unless you at least have a democratic majority in agreement.

Lots of agile proponents (I’m one) will argue for a shared workspace with separate offices where one can go to get real work done. However, I think the opposite is actually a better way to look at it – have separate offices as the norm, but a shared workspace for collaboration. You could have laptops for everyone and ask each teams to spend collaboration time there as needed; or you could have everyone spend one or two days per week there to make sure collaboration isn’t overlooked.

Generally speaking, I would suggest that the focus of your choice be on how communications can be improved. The answer might not have anything to do with office reconfigurations.

Seems to me that someone in WCF is causing a lot of people a ton of useless extra work.  If I remember correctly one .NET tenant is don’t throw exceptions when implementing a Dispose() method… look at the mess this causes.

http://msdn2.microsoft.com/en-us/library/aa355056.aspx

If someone is disposing of an object do they care if the Close() throws an exception?  Pretty unlikely – they aren’t planning to use the object anymore.  They just want the resources cleaned deterministically instead of waiting for the garbage collector.  If the developer isn’t checking that the data that came back is valid, then maybe there are other issues to worry about.  Dispose() could Close() the channel in a try and Abort() on exception and swallow the error if there isn’t a cleaner way behind the scenes to handle this.  This is all about handling exceptions on the right level.  Propagate the exception if you don’t know what to do, and don’t propagate them if you do!  Oh, and by the way (not that a good developer would do this but...), what happens when someone doesn't deterministically Dispose() the object and the garbage collector gets an exception?

I posted this comment in response to this post on ScottGu's blog (extract context information added here using [inline]):

I agree with Wim Hollebrandse and James [from comments] that your [Scott and David] example string.IsEmailAddress() was a poor choice - it encourages bad programming style. You [Scott] have a lot of influence both within Microsoft and without, please take more care in selecting examples that promote good style. The In() example was also questionable since the Framework already provides a Contains() method that does the same thing (maybe not as intuitively depending upon one's reading preferences).

While I love nearly all the new features that C# 3.0 and LINQ will introduce and the boost it will be to productivity, the new weapons will allow developers to not just shoot themselves in the foot, but to blow their whole leg off.

I hope the gains supplied from C# 3.0 and LINQ outweigh all the bad things developers will do with it and produce a sum total gain in overall code readability/usability.  Programmers will have to be that much more careful after this release.

----------------

I know this message may come across a little strongly and somewhat personal...  I only mean it as positive criticism and have a lot of respect for Scott in general and recommend his blog as a great source of information on ASP.NET, ASP.NET AJAX Library, and Visual Studio.

Phil Haack (http://haacked.com/) and I were discussing C# coding standards and he pointed me to Eric Gunnerson's C# Compendium blog http://blogs.msdn.com/ericgu/archive/2005/03/09/39... which I followed to read Cyrus' Blather blog at http://blogs.msdn.com/cyrusn/archive/2005/03/07/38...

Old - yes.  Interesting - definitely.

I love the comment left by Dave Aspinwall:

"I think Hungarian notation is great. In fact, it should be used for everything, not just code development. For instance, see how much clearer things are if we prefix all nouns with a 'n', verbs with a 'v', adverbs with a 'd', and adjectives with a 'j'. Vdoesn't nthis vlook jbetter?

Nthat's dnot dreally jenough, though. Jplural nnouns vshould dreally vhave an nindicator, "pl". plnsubjects vshould vhave a "sbj" and sbjplnobjects vshould vhave a "obj" nprefix. Nwe vcan vuse "tr" for jtransitive nverbs, and trvuse "int" for jintransitive nverbs.

Jour plndocuments vwill dthen vbe jmuch jclearer.

I'm relatively convinced the need isn't there for Hungarian notation in C# with the following possible exceptions.

I believe non type-safe languages need Hungarian (like JavaScript).

Long weary of the complexities of all the Hungarian prefix variations, in my development I've tended to stick with very simple conventions like i for all ints instead of n for count ints; f for all floating points and not distinguishing various subtypes (double-precision, single-precision); and lots of o's for user defined types.  I always minimize the length of prefixes, always s and never str for strings for example.  This has keep its use much more practical than the example from Cyrus' blog.

It is very hard to conclude on a standard for visual controls like buttons and textboxes on windows or web forms unless you follow VB-like conventions, which I've never really liked.  Why use txt when you could use tb for a TextBox or cmb for a ComboBox (i.e. dropdown) when you can use dd.  Besides that, there are so many different controls!  Coming up with a very streamlined set of miniscule prefixes that everyone agrees on is not an easy task.

I come from C/C++ background with some digressions into Java, VB, and JavaScript.  I would like some basic conventions that could be applied relatively consistently across all programming environments (including the database).

The tbl prefix that some people use in the database seems really awkward; after all, you always know when you are dealing with a table (FROM xxx JOIN xxx, etc) (I prefix views with v_), but it's the individual columns that you get screwed up with.  With this idea you can apply type mapping between various languages allowing the prefixes to always match.  However, inconsistent labeling by different developers and standards evolution can lead to different conventions showing up in different parts of code.  So is consistency worth the effort?

I used to take consistency to the extreme in the sense that even method parameters, etc. should be prefixed, but have concluded that members of the interface should be written for the interface - like properties - with no Hungarian.  I think it's about time to step away Hungarian in the rest of C#, mainly because with good programming and refactoring, methods should be kept concise and easy to understand.  Hungarian provides no real gains with well-factored code.  However, besides consistency argument, after reading this blog I realize why I've held back: because there is benefit in prefixes for showing scope.  For example, one thing I like is that a method parameter (ex. size) is named different from a local variable (iSize), from a member variable (m_iSize), and from a property (Size), but they might all refer to the same underlying information.  I would hate to name the local variable sizeTemp.  By the way, I was going to use _ for members, but went with m_ because VB wouldn't support variables starting with _.  Maybe that has changed recently, but I haven't used VB for some time now.  However, I've found another use of m_ because I can add s_ to isolate static members from instance members.  I don't want to add a prefix for a local variable, but following my argument through to its conclusion means doing so - does l_ make sense?

All this led to an epiphany regarding the how to handle visual elements.  Drop the type prefix, use only scope prefixes, AND add a visual scope prefix (v_??).  This might (not sure I've fully thought it through yet) solve the main issues.  I'm still not sure how (or if) this should apply to database columns either.  Does it make more sense to apply the Hungarian non-typed language exception?  Should I develop ANOTHER scope prefix (d_??)?  I don't like either option - I want to move to unprefixed columns, but it could be useful here.  This doesn't mean you'd have to prefix each column d_, but if you develop code that was accessing a size element from the database you might use d_ to clarify that it refers to a database mapped variable as opposed to a local, parameter, property, member, or visual element.