Darrell Norton's Blog [MVP]

November 2003 - Posts

• Low-tech Project Management

  Steve Maine tells us about his favorite project management methodology, wall-Gantts.  A wall-Gantt is a Gantt chart that is created with paper, string and note cards on a wall.  How's that for low-tech? Speaking from personal experience, there's nothing like a nice big visible physical artifact.  Probably the main benefit comes from the communication it enables.  Since we were living in a cube-o-minium at the time we couldn't make wall-Gantts, so we made do with white boards everywhere.  The" team cube" had 2, and 4 more were shared among six other people.  Very similar to Steve's experience, we would list all the tasks, who was assigned to them, whether they were not started, in-progress, or complete, and whether they were integration-testing complete.  Our tasks were up to 2 days, but it still worked very well.  Just the ability to mark something new, to show completion each day, seemed to be important.  Different colors also helped.  Green was reserved for complete, red for problem areas, black for the list of tasks (as unobtrusive as possible), the countdown for the iteration was in orange, blue for separating similar tasks by person, and yellow and purple were used for special stuff. I could look over at any time without leaving my desk and gauge whether we were on-time, behind, or ahead-of schedule (don't laugh, we often were!).  Sadly, my boss never figured out how to do the same thing.  So he would come down and ask me how the work was progressing standing right next to the chart.  I tried several times to explain it to him, he would say he understood, and would then wander off.  Two days later, right when I was in the middle of a task, he would interrupt to ask how the work was progressing. Being computer geeks we always try to create a software solution to this, a la Microsoft Project.  But the visible wall-Gantt is more than just a Gantt chart, it builds morale, serves as a social focal point for the team, and allows the celebration of success on a daily basis.  Until we can digitize all that, the low-tech solution will continue to reign supreme. Posted Nov 29 2003, 01:27 PM by darrell with 3 comment(s)

• Agile Software Development by the numbers

  From Agile Software Development, A DACS State-of-the-Art Report: Agile projects reported an increase in productivity of 15-23 percent, a 5-7 percent decrease in costs, and a 25-50 percent reduction in time-to-market. 84 percent of agile projects have 10 developers or less. Pair programming takes 15 percent longer but reduces defects by 15 percent. The single most difficult part in implementing agile methods (by far) is convincing management and/or other developers. Posted Nov 26 2003, 08:15 AM by darrell with no comments

• RSS Feed for ASP.NET Articles

  Just wanted to post the RSS feed for the ASP.NET homepage [via Kent Sharkey]: The 'recent articles' list from www.asp.net is now available via RSS (you'll see the shiny new XML button) or click: http://www.asp.net/modules/articleRss.aspx?count=7&mid=64   Posted Nov 25 2003, 10:54 AM by darrell with no comments

• The Benefits of Assigning a Non-default Value to Enums

  As part of our current application, we are often using enums for the various benefits they bring.  One problem I ran into, though, is not assigning a non-zero (for integer enums) default value to the enum.   Why would this be a problem?  Well, when I want to use Debug.Assert to check the preconditions on my method!  For example, I have a property whose value is an enum and the precondition is that this property has been set (a value assigned to it).  If the default value of the enum is zero, any time I check to see if the property has been assigned to, it always passes since integers without values assigned to them default to zero.  And zero is the default value of your first constant unless you override it.   For my purposes, I have found it useful to start numbering the values of an integer enum at one instead of zero.  That way I can write (in VB):   Debug.Assert((Me.PricingSize = PricingSizeEnum.FirstChoice) Or (Me.PricingSize = PricingSizeEnum.SecondChoice) Or (Me.PricingSize = PricingSizeEnum.ThirdChoice), "PricingSize must be defined before calling this method")   This also works (which is more intuitive but may not be exactly correct, can anyone help explain if this is ok?):    Debug.Assert(Me.PricingSize <> Nothing, "PricingSize must be defined before calling this method") Posted Nov 25 2003, 09:04 AM by darrell with 3 comment(s)

• Scrum Overview

  “Stable (defined) and unstable (random) systems are the extremes. What is novel is the concept of something in between – chaotic behavior. It refers to systems which display behavior which, though it has certain regularities, defies prediction. Think of the weather as we have known it. Despite immense efforts, success in predicting the weather has been quite limited, and forecasts get worse the further ahead they are pitched. And this is despite vast data banks available on previous experience. Every weather pattern, every cold front is different from all its predecessors.” Sound like any project you've worked on?  Then you need Scrum.  I've posted a Scrum Overview which will bring you up to speed on: The background of why Scrum works Current Scrum practices How to manage with Scrum Advantages and disadvantages of using Scrum, including when not to use it There are also links to the major web sites, books, and articles of interest related to Scrum.  All of this (cayenne-) peppered with my experience implementing Scrum on several projects. Check out the Scrum Overview now. Posted Nov 24 2003, 06:19 AM by darrell with no comments

• SQL Server performance optimization, the joy of indexes

  Another project was having some performance-related problems, so I was called in to review some of the stored procs to see if I could reduce the execution time.  As a brief overview, this part of the application pulled data from a data warehouse and stored it in a data mart.  Due to client requirements, all extract-transform-load was done via stored procs. After taking some measurements (mostly time-related) and familiarizing myself with what was going on, I started trying to make improvements.  One thing I noticed was that all the indexes were being created at the same time as the tables were, while they were empty.  So I changed the process to have all indexes created as the last step.  This reduced execution time by around 25 percent. Why?  Even though indexes usually speed performance, they have to be updated for every inserted row at the time of the insert.  So SQL Server was updating several indexes per table on the insertion of each row (and there were millions of rows inserted).  The indexes are necessary for the reporting part of the application, where response time is crucial.  But it was much quicker in this instance to wait, so that the creation of the indexes would only involve 1 pass through the table per index, instead of 1 pass per row. Probably the best thing to do would be to create the indexes on each table after it was filled with data, so it was more likely that the following stored procs would make use of the indexes.  But it was very easy and simple to move the index creation from the beginning to the end, and the likelihood of introducing errors was very low.  Sometimes this is more important when deadlines are looming than another couple of percentage points in performance. For more info on performance tuning: The definitive book I have found so far is Microsoft SQL Server 2000 Performance Optimization and Tuning Handbook, by Ken England.  If you haven't delved into query execution plans, statistics, covering indexes, etc., then pick up this book.  I found it to be a good reivew and I learned a few things, even though I have worked on performance tuning for some time. I have not read Microsoft SQL Server 2000 Performance Tuning Technical Reference, by Edward Whalen et al. It looks like a quality technical book, though. Veritas is also offering a free ebook, The Definitive Guide to SQL Server Performance Optimization eBook.  The only cost is to signup with a valid email address (hint).  I've looked over it, and it is very good for the price. Posted Nov 21 2003, 11:18 AM by darrell with 1 comment(s)

• A .NET Developer's Guide to Windows Security

  Keith Brown is developing an online book, A .NET Developer's Guide to Windows Security. Keith Brown has his new security book online. And when I say “online”, I mean he’s actually writing the darn thing right there on his web page. Even better, the book has an RSS feed. Subscribed! His last book was excellent – I’m sure this will be the same. [via Craig Andera's blog] He already has 36 items posted.  Highly recommended! UPDATE:  My mistake, it is Craig Andera (not Candera, as I had put originally).  Sorry Craig! Posted Nov 19 2003, 08:31 PM by darrell with 2 comment(s)

• "Investigating .NET" articles about reflection and .NET languages

  Jason Bock, author of Applied .NET Attributes, CIL Programming: Under the Hood of .NET, and .NET Security, is now posting a series of articles called "Investigating .NET".  These were chapters from a book he was writing, so the writing is good and there are code samples.  He will be posting them to his What's New page, which has an RSS feed. Articles that are already up include: Investigating Reflection Investigating .NET Languages Posted Nov 19 2003, 04:17 PM by darrell with no comments

• TestRunner add-in for Visual Studio updated to work with NUnit v2.1

  I noted on my .NET Test Driven Development article that I had problems getting TestRunner to work with NUnit v2.1.  Well all that has changed now.  Will Ballard sent me an email saying the he had updated TestRunner to play nice with the stock NUnit 2.1 and uploaded it to the site.  I downloaded it late last night, and now it works.  Here's a screenshot (note that this is inside Visual Studio!): You gotta love the .NET community! Posted Nov 18 2003, 05:50 AM by darrell with 7 comment(s)

• Review of Agile and Iterative Development by Craig Larman

  Agile and Iterative Development, by Craig Larman A lot of people are looking for proof of the effectiveness of agile software development methods.  Managers are looking for hard facts and data with balanced discussion on the pros and cons of agile.  Developers are looking for supporting material to convince their managers to use agile.  Customers are wondering if agile methods really benefit them and why there are so many changes to the current way of doing things. About the Book Craig Larman, author of the critically acclaimed Applying UML and Patterns book, seeks to fill that void with Agile and Iterative Development.  It is primarily a manager’s guide, so developers familiar with the various agile methods covered won’t find anything new.  Larman first works on iterative and evolutionary development, covering the benefits of timeboxing and incremental delivery.  This is pretty basic stuff for most educated managers, but if someone has not had exposure to it in the past it is important to review.  Then Larman moves on to agile methods and classifies them based on ceremony, which is the required and/or suggested amount and type of documentation, and cycle time, which is the length of an iteration. The most important section is the Evidence chapter.  There are statistics, example case studies, and thought leader commentary.  These facts cover a range of project size in developers and function points, time frames, agile methods, and technologies.  The evidence helps sell agile methods with a one-two combination punch of supporting agile methods and refuting common project management wisdom embodied in the form of waterfall processes. Although the reviews of the agile methods may not shed any new light on the practices themselves, Larman does include an interesting section on how to fail with each method.  This very effectively emphasizes the common misconceptions that non-agile managers have.  He also shows which way the method gurus envision implementing it (new test project, crashing project, etc.), and analyzes some of the method's strengths and “other” qualities.  The book is capped off with a good section on implementation tips, practices, and a FAQ. Bottom Line If you are a developer and your manager does not see the value in agile methods, or does not want to implement them 100 percent, buy this book and give it to them.  If they do embrace agile, first thank your lucky stars and then thank your managers with this book.  If you want to be able to cite facts and statistics supporting agile, buy this book.  But do not, under any circumstance, buy it thinking you will get something out of it development-wise.  That is not what this book is for. Posted Nov 16 2003, 07:45 PM by darrell with 9 comment(s)

• Review of Programming Visual Basic .NET by Jesse Liberty

  Programming Visual Basic .NET 2nd ed., by Jesse Liberty Probably the best way to learn how to code in any language is to program with the examples in the book.  I'm an experienced programmer in C#, but needed to get up to speed on VB.NET quick for some consulting work.  I won a copy of Programming Visual Basic .NET at a WeProgram.NET user group meeting, and started reading it immediately.  I skipped reading most of the explanations and went straight to the code (serious coders will understand this urge!).  Even without reading much of the text, the code examples, while unimaginative, were selected well enough for me to pick up on the language, including its idiosyncrasies (arrays in VB delimited using () rather than []).  I also like the fact that, for the text I did read, he explains why he is doing things a certain way.  I can see where this would be really helpful for someone just learning to program or making the transition to .NET. The only problem I really have with the examples is that it did not make clear what code was part of VisualBasic interop.  Since I am now coding in two .NET languages, I don’t want to have to remember CInt for one language and Convert.ToInt32 for another.  I know this book is geared toward experienced VB6 programmers, but let’s start doing things the .NET way and not let old habits resurface.  That’s why it’s here. Overall, I gave this book 4 stars (out of 5) on Amazon. Posted Nov 15 2003, 07:59 AM by darrell with 5 comment(s)

• Which CLR-compliant language will you use in Yukon, Part 2

  I posted a link to the SQL Server magazine poll in an earlier post.  Well, the results are in!  It seems C# is favored, with VB.NET and T-SQL about the same in second place. Which CLR-compliant language will you use to write server-side code when Yukon is deployed? Total Responses: 469 Visual Basic .NET    29% C#    39% C++    1% Other    3% None--we're sticking with T-SQL for server-side code    27% Posted Nov 14 2003, 11:23 AM by darrell with 1 comment(s)

• Is it possible to set the value of a read-only textbox client-side and access the result server-side?

  I coworker of mine is having trouble accessing the value of a read-only textbox set via client-side script: If you are like me you want to use as much client-side power as you can.  Part of communicating the results of this power to the ASP.NET code on the server often involves populating an from client script so that you can read the corresponding object on the server.  Often, though, we don't want the user to be able to interact with the textbox on the client.  If we don't want them to see it then you can set the CSS properties (style= or class= or by a selector in the CSS script block) to hide or not display the textbox.  That's easy enough.  But what if you want the user to see the textbox but not interact with it?  You'd think that setting the enabled attribute on the element would be the thing, right?  Well, sure, that looks like it works.  The textbox shows and your client-side script can interact with it.  What's the catch? None if you initially populate the textbox's text property from the code behind.  Then it all is good.  But if you start with an empty textbox, populate it on the client, and then attempt to read the value on a postback you will get String.Empty no matter what is actually in the textbox. Anyone have a reason or a workaround? Posted Nov 14 2003, 05:37 AM by darrell with 8 comment(s)

• .NET Test Driven Development update

  I've updated .NET Test Driven Development with an additional 32 links, doubling the original number of links.  Updates include: Lessons Learned in Software Testing a book by Cem Kaner, James Bach, and Bret Pettichord Testing for Programmers - notes from a half-day course (114 pages!) by Brian Marick, uses JUnit Brian Marick's other writings Bret Pettichord's Publications Cem Kaner's articles James Bach's articles Most of these, as you can see, are “testing” related, as opposed to Test Driven Development.  I've found that writing unit tests has become much easier the more I've learned about testing in general.  If you don't read anything else, check out the Testing for Programmers notes. Posted Nov 13 2003, 05:03 AM by darrell with no comments

• What's that smell? Bad code smells and what to do about them

  Steve Maine writes an excellent post on "code smells". Things that I try to keep a look out for: Code that seems too familiar. If it seems familiar, it probably means I've already written something similar elsewhere and should think about refactoring to eliminate duplication. Functions that scroll off the screen. If my function can't fit on one screen, it's probably doing more than one thing. Time to think about splitting it up. Nested “if” statements. Conditional logic is inevitable, but a well-factored solution doesn't rely on a lot of it to get the job done. If I'm nesting a lot of if/else if/else statements, I'm not thinking correctly. This stems from the general thinking that good code has a low cyclomatic complexity. Functions that take many parameters.A good object-oriented solution keeps state around in object-level variables, not parameters. Chances are, if I'm passing a lot of parameters to a function I should think about introducing an encapsulating abstraction to reduce complexity. Classes that have many public members. A good class abstraction serves a specific and defined purpose. If I see a class that exposes a multitude of functions via its public interface, it's time to go back and look for potential duplication. Chances are, some of these API's are redundant or unnecessary. Variables, functions, or types that have awkward names. This one stems from a conversation I had with Brian Jackson a while back. He made the observation that the elegance of his code seemed to be directly indicated by the ease he had in naming his functions. Good functions should do one thing and do it well. When they're written this way, it's very easy to come up with a meaningful function name -- it obvious what the function should be called. Same thing with variables and classes. Thus, if I find myself scratching my head trying to come up with a name for a function I'm implementing, it's usually a good indication that I need to rethink what I want that function to accomplish. Posted Nov 12 2003, 05:52 AM by darrell with no comments