You Gotta Stand Up For What You Believe In

Built To Last and Good To Great left me with a lot of ideas to digest, but I'd like to touch on two of them. In Good To Great, part of the Hedgehog Concept involves the journey in finding the "core" that you believe in. In Built To Last, half of the foundation for building a visionary company is "Preserving the Core."

How do you find the core? It has to be something you're passionate about. Philip Morris is passionate about offering products and defending your choice to use those products. You may not agree with that stance, and if that's the case, working at Philip Morris is probably not a good idea. Nordstrom's is passionate about customer service - almost fanatically so. If you aren't, you won't fit in.

These companies spent a while looking for their core values. Once they found them - they were passionate about keeping them, and developing a company where the values would flourish, by hiring (and keeping) individuals who shared those values.

This is of the utmost importance. At the point where you're looking for employment in your life, your core set of values is probably established. It becomes harder to change these as you grow older. Don't be afraid of what you truly believe in. If you're passionate about something, find and surround yourself with others who share these values. By the same token, a company should actively seek to hire individuals that identify with it's core values.

For software companies - I think there is a key difference between core values and core competencies. I feel far too many recruiters and jobs focus on technical skills that can be acquired by any good developer in a few weeks. Focus on the values the developer holds. Are they disciplined? Are they enthusiastic? These are more important, as these traits will drive them to always be learning the technical skills they need to help them succeed (and your business, as well).

Disclaimer: There is still a core level of technical competency that any developer needs. I think it's hard to really quantify it, but anyone working as a developer definitely needs technical skills. They are, after all, what allows us to do our jobs. I just don't feel that measuring someone solely by their laundry list of buzzwords on their resume is a good indicator of their true worth.

FindControl and UniqueID

The FindControl method is not recursive. Should have done that Google query before I spent 3 hours debugging.

Imagine you've gotten a page that adds user controls very late in the page lifecycle - after Init, in any case. Like any good control developer, you're definitely going to recreate the control tree after postback, but you have some additional requirements. In addition to adding the control to the tree, you need to keep track of certain types of controls, and re-apply some properties to them. Like, a "collapsed" property, for instance.

So, you throw some control ID's into a StateBag (I really like that class name) to retrieve later, to apply the properties to each control. You have the ID, and you have the control type - should be easy to find the controls on each page, and then apply properties, right?

Wrong. Not if you don't know where in the tree it is. Page.FindControl(controlID) doesn't work if it's deep in the tree. However, using our handy-dandy Reflector, we can see that FindControl uses ID and UniqueID, which:

Gets the unique, hierarchically qualified identifier for the server control.

Ahhh...just what I need. The ID and where it is in the tree - all without having to to implement FindControlRecursive (for now).

Software Companies and Discipline

Anderson brings up to my next point - what would you consider discipline in a software company?

The first discipline concept is Disciplined People. Most top-notch software shops know how to hire disciplined employees - individuals who never stop learning, and who are committed to building (and shipping) great software. You want everyone on board to be serious about their craft (whether it is a developer, tester, or manager). They need to have both the guts and the ability to take your company to Great (as capitalized by Jim Collins).

The next concept is Disciplined Thought. You've hired the right people. They have the raw abilities, and they have the gumption to perform at their best. Now, comes the unified part. You have to harness all of that discipline and focus it on your software. This is hard. You need to create a sense of unity. It's not the testers vs. the developers. It's not management vs. everyone else. The entire team needs to be "signed up" to deliver Great software. Again - if you've got Disciplined People, this part should be cake.

Finally, there's Disciplined Action. This is definitely the hardest part to "get right." It's crucial that the first two ideas happen before this one can be truly successful. I myself have a hard time with it - undisciplined thoughts that turn into actions can make it look like it's a failure in execution, rather than planning. (Especially when you have several successes under your belt.)

Developers are notorious for being bleeding-edge adopters. It's practically a badge of honor to be running nothing but beta software on one's machine. I'm no exception - it's happened in the past, and right now I've got two different versions of Visual Studio running side-by-side. What happens is if you let this tendency run wild in your software, you will have problems. I'm not saying new technology is a bad thing. I can't wait to replace some of my Dictionaries with HashSets. LINQ is undoubtedly cool. And don't get me started on lamdas. But, there's no way I would try to integrate .NET 3.5 into an existing project that needs to ship anytime soon. I've been down that road before, and I know where it ends. (Hint: it's a particularly "deathly" kind of "march.")

You get the right people, who will make the right decisions, and execute them properly. For a software company, this means hiring people who will ship great software, and base their decisions and actions around that concept. Developers write high quality, unit tested code. Testers make sure the code meets requirements and is of high quality. Managers keep the machine running smoothly, and block any attempts to foul it up. Business analysts figure out what the customer really wants. And no one makes decisions that will run contrary to the desired outcome - shipping Great software.

Discipline and Unity

I've just about finished up Jim Collins' Good To Great audio book, and I've recently finished Dynamics of Software Development by Jim McCarthy. After reading/listening to both, I've come to the conclusion that:

1. For a software team to become successful, you need a common understanding of the goal. Every member needs to know what the final desired outcome is.
2. Every team member also needs discipline. Jason Alexander sums it up better than I could.

With discipline and a clear goal, everyone focuses on the outcome with all the effort they can muster.

Now, there are obviously more factors that contribute to a successful team, but I feel like these are some of the most important ones. If your team has these qualities, you're definitely on the right track.

Raising the Lowered Bar – ASP.NET and the Barrier of Entry

Developers, developers, developers! It's been Microsoft's mantra for a long time. They had the VB developers "back in the day" (a Tuesday, I believe) and when .NET came out, they needed a way to keep them.

So, what do you do with a bunch of developers that don't want to learn a new way of doing things? Simple - don't make them learn.

ASP.NET has a low barrier of entry

So, now, there's this new .NET "thing" and there's all sorts of ways to make a presentation layer for your applications. You can start using WinForms, or you can use ASP.NET. (Now, you can also start using WPF, or Silverlight, but we're talking about the dark ages of 2002. Bear with me.) From what I recall, it seems like that Microsoft was pushing ASP.NET pretty hard, and leaving WinForms as a not-quite second class citizen.

So, ASP.NET. It's fantastic. I loved it and I still think it's a fantastic platform for any development - web-focused or otherwise. Microsoft did too, and they did several things to make it easy to start developing applications in ASP.NET. They used a lot of conventions from the old VB world of Forms development (TextBox, Label, Button) for the presentation, and they presented a fairly robust event-driven model for UI interaction. They kept the same basic state management tools available to you from ASP classic, and tried to make it as easy as possible to migrate existing ASP applications to .NET.

(Side note - anyone who's actually done a migration like that with a "real" application knows that it's not trivial at all. But Microsoft did try.)

What Microsoft failed to do with ASP, and what they sort-of did with ASP.NET was abstract the messy land of web development, with it's:

• HTTP verbs (POST, GET)


• Javascript


• the HTML DOM


• CSS


• Different browser issues (usually related to the items above).

They shipped a bunch of tools (DataGrids, several wizards) that would allow you to make your easy, cookie-cutter "enter some data and display it back to the user, or throw it in the database" applications very quickly.

I know I'm glossing over a lot of stuff. Bear with me.

Rails and Scaffolding

What? Ruby? Rails? Blasphemy!

Seriously though, this is great stuff. I have yet to do more than play with it, but I've made a commitment to start learning something new, and Ruby is a start.

So, what do I do? I start reading blogs. I've been reading a lot of Giles Bowkett. He's abrasive, but he takes a side, and I like that. Something he touched on is part of the inspiration behind this whole article:

I recently tried to get the Rails core team to switch the for loops in the scaffolding templates to iterators, on the grounds that this would encourage new Rails programmers to use iterators instead of repeating their bad old habits with for loops. I failed completely. Josh Susser said that replacing for loops with iterators would set up a barrier to adoption for new Rails programmers, and that was that. The idea didn't fly for a second.

So - barriers of entry <=> Bad.

The whole philosophy behind the Rails team is to get programmers using Rails (and Ruby). The easier it is to switch, the better.

The state of Web Development Now

So, what's happening now? You don't find a lot of WinForms developers, for one. I've been on job hunts recently, and let me tell you - Microsoft shops don't care about WinForms. They all want ASP.NET. (Or they're stuck supporting their old VB apps. But they're moving them to ASP.NET.)

So, now all of the developers working on Microsoft's platform have ASP.NET based applications. You have zillions of web applications out there that basically all do the same thing - enter data into a database and display it back later. And a lot of them are exactly the same. Sure, the database is different, and the colors are different, but there's not a huge differentiator in applications that are developed for ASP.NET, if you stick to the DataGrid/GridView application model.

Where you find the truly outstanding applications now, is both a great idea, with great execution, in ways that make that web browser dance. And there's frameworks out there that try to help you (ASP.NET AJAX, control suites like telerik or ComponentOne).

However, several of these still provide somewhat leaky abstractions. FileUpload controls don't work correctly in UpdatePanels. Validators don't work correctly anymore. ComponentOne's grid looks great, but only if you're willing to put up with it's bloat. (It emits a TON of code to the browser.)

However, think of those applications that just give you the "holy shit" moment when you figure out what's really going on.

• GoogleMaps


• Gmail


• VirtualEarth


• Community Server


• Basecamp

I'm sure you've probably got your own list, but these are ones that really stuck out in my mind. And what do they have in common? These applications were built with the understanding that the browser is fickle, but powerful, and take advantage of the HTML/CSS/Javascript "mess."

Go Learn Something!

So, what's the point of all this? Go learn what you're emitting to the browser! Here's some problems that, without knowing about the HTML DOM and Javascript, I would have had a nightmare of a time dealing with.

• The ASP.NET Label - is there any more mis-used control? This needs to have the AssociatedControlID property filled in, so that it actually renders as a <label> or you'll end up with a <span>. Heaps of problems there. Much better to use a Literal if you're just trying to throw some text up on the page.
  
  Side note - DataBinding (for globalization), in my experience, is easier with a Label. It has all the properties that you'll need to globalize. So, what can you do? Override the default rendering (as a <span>) with something else if it's screwing up your CSS. Or roll your own control. The CSS Friendly Adapters are a good place to start.



• The DataGrid, or the GridView. Good for simple stuff, but I bet you won't find many of those on anything that is public facing - too much to send up to the browser. Use a Repeater instead.
  
  
  Scott Watermasysk has a great article about these tips, and others as well.
  

I'm sure there are other problems out there, but these are just some of what I've encountered. But, without the big picture, I couldn't have solved them as effectively as I would have liked.

Congratulations! You've reached the end. Thanks for reading, and I'll (hopefully) have some more in the future.

Get XmlDocument from a class

So - I've been trying to find an easy way to add a ToXml() method to a lot of objects lately. Here's what I've come up with:

MemoryStream ms = new MemoryStream();
XmlWriter writer = XmlWriter.Create(ms);
XmlSerializer xs = new XmlSerializer(this.GetType());
xs.Serialize(writer, this);
XmlDocument doc = new XmlDocument();

// Need to start at the beginning of the MemoryStream
ms.Seek(0, SeekOrigin.Begin);

doc.Load(ms);
return doc;

The Seek method took me the longest to figure out. I kept getting a "Root node is missing." exception.

Hope this helps someone.

CodePlex and Subversion

As I've posted about before, Subversion is a great tool. It's

• Open Source
• Free
• Fast
• Easy

Rob Conery and his awesome SubSonic project are hosted on CodePlex, which uses TFS as it's backend. I'm working with TFS now (at work) and it's a great solution for the teams we have here. But, I don't think it's appropriate for the CodePlex community.

And Rob's losing contributors - something no open source team wants to happen.

So - here's my two cents. CodePlex should switch to Subversion. It's a much more appropriate source control tool (for this type of collaboration) and I'll even go out on a limb here and say that if they do switch, I'll personally see what I can do to start contributing to SubSonic.

Automatically insert SortOrder value in SQL

So, the other day I ran into an interesting problem. I've been using CodeSmith and .netTiers to develop all that "boring business/data access code" for an application at work. One of our requirements was to have a list of things with a user-specified sort order.

So, I added a SortOrder column to the table (not sort_order, but more on that later), and ran my code-gen. I didn't want to put the "automatic sort order insertion" into a stored procedure (since they're all generated), but I also didn't want to have to hit the database several times just to figure out what the next value should be.

Then someone showed me that you can have a function for a default value in a column in SQL Server. I knew this instinctively (NEWID() for a uniqueidentifier, or GETDATE() for a "date inserted" column) but I hadn't thought about using my own function.

So, here it is:

DECLARE @newMax int

SELECT @newMax = MAX(SortOrder) + 1 FROM TableWithSortColumn WHERE SomeForeignKeyId = (SELECT SomeForiegnKeyId FROM TableWithSortColumn WHERE Id = (SELECT IDENT_CURRENT('TableWithSortColumn')))

RETURN @newMax

I just created the function, set my default value for the sort column to dbo.GetNewSortOrder() and

Disclaimer: I'm not particularly sure this is really the right place to do this type of thing. If anyone has any suggestions or comments, please let me know. If you think this is a terrible idea and will cause my application to start fires and kidnap small children - definitely let me know. I'd like to avoid any legal entanglements.

Battlestar Galactica and Developing Software

For Christmas this year, my wife got me some really cool gifts. And a few days ago, I read an article that Joel linked to in his Dreaming in Code article. It got me to thinking, especially Joel's Yiddish to English analogy.

The two books, in particular, were very good. The meat of the books focuses on the creation and inspiration for the episodes, including the starting concepts (the episode Scar was initially just an idea: "the Red Baron episode") and their evolution into what I saw when I plunked my butt down on the couch with my wife and friends every Friday night.

There seemed to be a lot of vague ideas that went from brainstorming sessions, to screenwriters, to the producers, back to the screenwriters, to the producers, back to the screenwriters, to the producers, the director, back to the screenwriters (yes, I am repeating myself on purpose), and so on. And once a script was written, the actors would do take after take until the director was satisfied.

It got me to thinking about how many teams approach software specifications, estimates, and that oh-so-fuzzy factor I like to call "Client Satisfaction." This client can be the general public (if you do shrinkwrap software), the big multinational corporation that's going to send your consulting business into the stratosphere, or your professor grading your midterm project.

You start with an idea: We need an "inventory system." If you're like some custom-software consultants, at this point you send a fleet of analysts that "speak customer" to try to figure out how to translate "inventory system" into a 200-page specifications document.

Then, the document goes to the developers to estimate, of if you don't want to use that word as a verb, to give an estimate. Read that last word again. Estimate. Dictionary.com defines estimate as:

to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately

or

a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work

Notice the key word in both definitions: approximate. We all know what that means (as I'm sure you knew what estimate meant, but I'm trying to illustrate something, so bear with me.)

Approximate. Why is it that an approximation in many software shops is treated like a prediction from Nostradamus, and not more like a "I hope it takes this long, but maybe not." If you're someone in charge of scheduling, please don't divide this by some number (usually 8, which is wrong), figure out which day of the week that falls on, and sign a contract with a client gauranteeing that it'll be done on that day. You'll be sorry.

In the past, I've been tasked with estimating very large pieces of software. There's been some with very well-written specification documents, and most of what has been asked of me is not difficult, at first glance. There's been others where it was just an idea.

Usually, when it comes down to giving the final "magic number" of hours, it's not that that number is balked at. It's that several times, scheduling based solely on that number of hours usually results in missed deadlines, frazzled developers, and perhaps most importantly, unsatisfied customers.

Why unsatisfied customers? In my experience, when I've developed larger applications, with a traditional BDUF pattern, the customer won't see a product until about 75% of development is done. By then, they've probably formed some more concrete ideas in their heads of what they want, and since they're (most likely) not developers, it may not be what you give them.

What does this have to do with TV? Many of the roles are analogous. Actors are developers - their performance can be thought of as the actual computer. Screenwriters function as a business analyst. The director is the client. (You could argue they're QA, and the client is the viewer. But it's my blog, so I'm making the analogies.)

There's lots and lots of revisions in this process. The client gets immediate feedback from the program's output, and if he doesn't like it, he asks the developer to try again, "with feeling."

This is something that many need to realize about developing software. The client has a fuzzy idea about what it is they want, and it's hard to nail that down in "specifications documents" or "business requirements." I'm not advocating throwing these documents out the window - well-written specs are invaluable to have. They need to evolve with feedback from the client - and it needs to be sooner, rather than later. And you better schedule that in too - because no client is ever satisfied with the first draft.

That's why good actors are paid lots of money - they start to instinctively know what it is their client wants and can give it to them with the least amount of iterations. I think that people who serve this role in the development world, like free electrons, or business analysts that are "good at dealing with people, can't you understand that?" are who you want on your team. They can get the satisfaction up high with the fewest iterations. They grok what the customer really wants.

So, remember this: clients don't know exactly what they want. They have an idea. Help them shape and mold that idea until they look at you give them and say "YES! That's what I've been after." Be sure to build that into your schedule too.

It would be nice if we could have a "satisfaction requirements" document, though. That's definitely the answer.

Scott Guthrie came to Dallas

So, last night Anderson, Zach and I went to the North Dallas .NET Users Group meeting, with a very special guest: Scott Guthrie!

It was a great presentation. From the slides he was showing - looked like a presentation he'd already given at Tech-Ed this year. The information was great, and you can get the slides and source code he demoed last night here (not available yet, but he assured us it would be soon), so I won't go over everything, just what I was excited about.

First, CSS Adapters. Very cool, especially if you have, or you've got some people with the mad CSS skillz. His overview of speeding up build performance and the "new" Web Application project model for ASP.NET websites was good to see too. And of course, server-side comments. He talked about Atlas ASP.NET AJAX (that's a lot of acronym) too, but there's a lot to that and I won't go into it here.

LINQ was great - I see a lot of possibilities there. There were some concerns in the audience about LINQ was trying to "replace DataSets." Personally, I don't see it that way - it's just a new way to strongly-type your data layer. The thing I thoguht was cool was the possibility of doing joins across different data sources - a SQL database and an XML file, for example. That may be more of a "look what I can do" thing to try, but it's interesting to think about. Extending the LINQ provider model was also something that was exciting - apparently, there's already and Amazon LINQ provider out there that lets you search for books directly in C# code without having to wire up the Web Service.

Plus, I won a copy of Quicken 2007. Yay?

Edit: Updated link to Scott's blog post.

Message Massagers

This post will not be about Subversion.

Something Anderson talked about recently was how the Provider Pattern wasn't just for ASP.NET. He offered up a good example, but I thought I would expand on it a bit.

Something I've had great experience with is an application that I like to call a "Message Massager" or a "Message Munger" (pronounced mun-jer). Basically, the program flow is:

1. Get input from some entity A
2. Munge/Massage the input
3. Give the input to entity B
4. Get response from B
5. Munge/Massage response
6. Give the respone to A.
7. Lather, rinse, repeat.

When I started, I hadn't really thought a lot about how I could make things easier on myself. I created all sorts of classes and schemas, and it never clicked that I was essentially doing the same thing over and over. After reading his post, I saw several ways I could have made my (and the developer who adopted my applications) life easier.

I won't go into the details of implementing a Provider pattern for this type of application - Anderson laid them out pretty well. Something else that I came across recently, though, might also be of interest. Eric Sink recently offered up an implementation of Map with multicore support in C#. Since most of the messages that I was munging (yes, that's the technical term) were independent of each other, this might have sped up performance quite a bit - several times my applications were dealing with 500-1000 messages per iteration. This is all just speculation, since I don't work on those applications anymore, but it's something I'll have to keep in mind for the next time someone hands me a stack of paper that defines an interface for communicating with some huge system.

The Subversion Conversion

If you've ever looked for a blog on software development, you've undoubtedly stopped off at Joel Spolsky's little corner of the inter-web. And if you have, then you've probably read The Joel Test. That first item on it - "Do you use source control?" is something I'd like to talk about over the next few weeks.

If you use Visual Studio, you've at least heard of SourceSafe. Heck, you've probably used it, or are using it right now. Would everyone reading please raise their hand if they really, really like SourceSafe? Do you feel warm and fuzzy inside knowing your code is "protected" inside of SourceSafe? Anyone?

No? Me either.

So, what do you do? You can either live with it (not a good idea) or you can change it. Now, in an ideal world, you'd be able to either convince your boss/CFO/purchasing department to whip out the credit card and buy everyone Team System. Try it. If they react the same way most would (and to be fair, it is approximately 1 hojillion dollars per developer) then you've got to find something cheaper. Or, dare we hope, free.

Enter Subversion. It's open-source and free-as-in-speech, and best of all, some of the CVS developers that got tired of it work on Subversion. So you know they've got some background on the subject.

"But Nic", I hear you say, "isn't getting this running for a group of developers who are familiar with SourceSafe and doing things Their Way going to be a pain?"

Yes, probably. But, instead of dealing with quirks and worrying about database corruption and that offsite developer whining about how slow it is, my company decided to take a more pro-active approach. I'm a firm believer in Getting Things Done. And if I have to "deal" with my source control system, I'm not Getting Things Done.

So, go ahead and download the latest copy for your environment from here. And if you're using Windows, and if someone tells you that you must have Apache installed before you can use Subversion, they are either a LIAR, or simply confused. You only need Apache if you're going to be doing http/https-based access or want to do some fancy authentication (like Windows Domain). For testing on your local machine, you don't need it.

If you're a Windows user, definitely get TortoiseSVN. It's a Explorer Shell Extension that encapsulates just about everything you'd do with the command-line version into that pretty GUI that we Windows users need. If you're using Visual Studio, then you should also pick up AnkhSVN. It's a plug-in that will enable SVN commits/updates from within Visual Studio, and it knows not to check in your compiled DLL's, or the SUO files.

From my testing, I've found it best if you have all of the projects within a solution in the same working directory. This will probably not be the way that Visual Studio is doing things for you - it defaults to putting ASP.NET websites in one directory, and everything else in another. For both Subversion's sake, and your own, keep everything in the same directory. Cassini can run a website wherever you put it. If you're still building .NET 1.1 websites, you can also setup IIS to have a website wherever your working directory is, and the applications should get created automatically when you pull them down, or when you create new ones. I'm still experimenting with this, so please leave me some feedback if you have any insight on this.

If you're serious about taking this plunge, then I highly recommend you first go pick up Pragmatic Version Control: Using Subversion. It's short, and has a great overview of what someone who likes to Get Things Done should be doing with their source control system. It says version 1.3 on the cover, and 1.4 is the latest version as of this post. Nothing significant from a user's perspective has really changed, it's a lot of internal improvements, API changes, and some administrative enhancements.

Now, as far as a company-wide conversion, we haven't taken that plunge yet. But, we will. We need to figure out some best practices, repository structure/locations, and the general process first. So, stay tuned. We're in this together.