Scott Hanselman

ADD and Flaming Potato Development

June 21, '07 Comments [4] Posted in Musings | Programming
Sponsored By

Scott Berkun has a great article over at his blog about *sshole Driven Development, or "ADD."

"Any team where the biggest jerk makes all the big decisions is *sshole driven development. All wisdom, logic or process goes out the window when Mr. A is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway."

Of course, one should look to themselves and their own team first to make sure that you're (or me, for that matter) not Mr. A.

I've worked at places that seemed to promote what I've called Flaming Potato Development, also called "Not My Problem (NMP)"  Development in the comments on Scott's Blog:

"...in which all complex, complicated, expensive, or otherwise troublesome decisions/features/issues are pushed into someone else’s module?"

Great stuff, do check it out. Also, I encourage you to check out Scott's book on The Myths of Innovation, it's supposed to be pretty good, I'll be picking up a copy this weekend.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

The CodingHorror Ultimate Developer Rig Throwdown: Part 2

June 20, '07 Comments [47] Posted in Musings | Reviews
Sponsored By
NVidia MotherboardI've gotten permission from the wife to build the Ultimate Developer Rig that we talked about in Part 1. I debated getting a MacBook Pro when the latest stuff came out at WWDC, but since I already have a Mac Mini that I hardly use, but that does run Rails happily, so I'm going to wait a year or two to get a fully loaded MBPro.

Originally I'd figured I'd shoot the moon and buy a mega-machine for and obscene amount of money, but then I realized that not only do I not have mega-money, but at some point one reaches a point of diminishing returns.

I want this machine to be ridiculously fast, but I want the price/performance ratio to be ideal.

Here's what Jeff and I finally came up with.

Once You Know, You Newegg

In the coming few weeks we'll put it together, and then add Jeff's special touch which will include sound damping and overclocking. There will be pics and details on the performance before and after, and we'll see what this $1900 machine will be capable of.

Technorati Tags: , , ,

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Assembly Fiefdoms: What's the Right Number of Assemblies/Libraries?

June 20, '07 Comments [29] Posted in Learning .NET | Programming
Sponsored By

iStock_000003315647XSmall Deciding how to physically partition up your application isn't a .NET specific topic, but I'll use the word "Assemblies" and use .NET terminology since we work largely in .NET.

What's the right number of assemblies? When do you split up functionality into another assembly? Should you use ILMerge to make a single über-assembly? Perhaps one class or one namespace should be inside each assembly?

Here's my thinking...organized very simply.

  • The number of assemblies should NOT relate or correlate in any way to the number of developers.
    • Just as your logical design doesn't have to be paralleled in your physical deployment, your number of employees shouldn't affect the number of assemblies you have. If you are a single developer, or if you're 50, there's a "comfortable" number (a number that's right for that app) of assemblies your application should have , and that number doesn't change if you add or remove people.
  • Your source control system shouldn't affect your assembly count.
    • May karma help you if you're using Visual Source Safe or a source control system that requires exclusive checkouts, but try to avoid letting your source management system indirectly or directly put pressure on developer to move towards a certain number of assemblies. Avoid Assembly Fiefdoms.
  • 1 Namespace != 1 Assembly
    • Consider first organizing your code logically (namespaces) rather than physically (assemblies). Use namespace hierarchies that make sense. System.IO and System.Compression and System.IO.Ports come to mind.

Robert Martin has an excellent PDF on Granularity, while focused on C++, the concepts aren't C++ specific. He has a section called "Designing with Packages" where he asks these questions, that we should ask ourselves when we start organizing an application. Substitute "packages" for "assemblies" if you like. He defines a package as a "releasable entity.":

1. What are the best partitioning criteria?
2. What are the relationships that exist between packages, and what design principles govern their use?
3. Should packages be designed before classes (Top down)? Or should classes be
designed before packages (Bottom up)?
4. How are packages physically represented? In C++? In the development environment?
5. Once created, to what purpose will we put these packages?
[
Robert Martin's "Granularity"]

He then goes on to answer these questions. Do read the PDF, but here's some terse quotes along with my own commentary:

"The granule of reuse is the granule of release."

If you're creating a reusable library or framework, think about the developer who is "downstream" from you and how they will reuse your library.

"The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all."

Not only this, but you reuse all their dependencies. Consider what the developer will be creating with your library and if he/she needs to include other assemblies of yours to accomplish the goal. If they have to add 4 assemblies to implement 1 plugin, you might consider rethinking the number of assemblies in your deployment.

Consider the effect of changes on the user of your library. When you make a change to a class, perhaps one that the user/developer doesn't care about, do they need to distribute that newly versioned library anyway, receiving a change in a class they didn't use?

"The classes in a package should be closed together against the same kinds of changes."

Developers don't usually use/reuse a single class from your assembly, rather, they'll use a series of related classes, either in the same namespace or in a parent namespace. Consider this, and the guideline above when you decide what classes/namespaces go in what assembly.

Classes that are related usually change for related reasons and should be kept together in a related assembly, so that when change happens, it's contained in a reasonably sized physical package.

"The dependant structure between packages must be a directed acyclic graph."

Basically, avoid circular dependencies. Avoid leapfrogging and having a (stable) Common assembly dependant on a downstream assembly. Remember that stability measures how easily an assembly can change without affecting everyone else. Ralf Westphal has a great article on Dependency Structure using Lattix, an NDepend competitor. Patrick Smacchia, the NDepend Lead Developer, has a fine article on the evils of Dependency Cycles.

Ralf has some very pragmatic advice that I agree with:

"Distinguish between implementation and deployment. Split code into as many assemblies as seems necessary to get high testability, and productivity, and retain a good structure." [Ralf Westphal]

This might initially sound like a punt or a cop-out, but it's not. The number of assemblies you release will likely asymptotically approach one. It'll definitely be closer to one than to one-million. However, if you ever reach one, worry, and think seriously about how you got there. 

Udi Dahan commented on Patrick's Guiding Principles of Software Development and said, quoting himself from elsewhere (emphasis mine):

In the end, you should see bunches of projects/dlls which go together, while between the bunches there is almost no dependence whatsoever. The boundaries between bunches will almost always be an interface project/dll.

This will have the pleasant side-effect of enabling concurrent development of bunches with developers hardly ever stepping on each other’s toes. Actually, the number of projects in a given developer’s solution will probably decrease, since they no longer have to deal with all parts of the system.

I would respectfully disagree with the bolded point and direct back to the principle that team structure should never dictate deployment structure. A good source control system along with pervasive communication as well as good task assignment should prevent "stepping on...toes." Sure, it's perhaps a side effect, but definitively not one worth mentioning or focusing on.

What's the conclusion? Consider these things when designing your deployment structure (that is, when deciding if something should be a new assembly or not):

  • Where will it be deployed?
    • Remember that compile-time references aren't necessarily runtime references. Assemblies aren't loaded until the code that uses them is JIT'ted.
  • Think about where your 3rd Party Libraries fit in. Are they hanging off your "root" assembly, or are they abstracted away behind a plugin assembly?
    • Consider putting "undesirable dependencies" as far away from your main stuff as possible. Don't get them tangled in your main tree. "Things burn, Colonel."
  • If you're making a library, think about how many dependencies "come along for the ride" when your downstream developer/user does an Add Reference.
    • If they have to add 4 assemblies to make 1 plugin, that's weak. (DasBlog has this problem with custom macros, we force you to add 2. That's lame of us.)
  • If you're big into plugins and you're *all about* interfaces, do consider putting them in their own assembly.
  • Consider grouping assemblies based on shared functionality, where Assembly == Subsystem, while watching for cycles and in appropriate, ahem, coupling.
  • If you notice that some assemblies seem to always go together, always versioning and changing together, like peas and carrots, perhaps they should be one.
    • Notice "natural clumping" and consider if that clumping is happening for reasons of Good Design or Bad Design, and act accordingly.
  • Personally, while I think ILMerge is a very cool tool, I have to find a good reason to use it in the Enterprise, except for when releasing small XCopy-able utilities to end-user's machines where I really want a single file.

What IS the right number of assemblies, Dear Reader?

Technorati Tags: , , , ,

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Flashing the Firmware of an Xbox MN-740 Wireless Adapter to a D-Link 108AG to support WPA Security

June 18, '07 Comments [4] Posted in Gaming
Sponsored By

A few years back I picked up an Xbox MN-740 Wireless Bridge to make my original Xbox wireless-enabled. It worked great.

Recently I did a network audit for our home and realized that we were running WEP for security. It was probably set this way when I upgraded us to FIOS. I switched the Router over to the more secure WPA.

Aside: I encourage you to switch over to WPA as well. Apparently WEP can be cracked in minutes with free tools. Also, hide your SSID.

I then went to each of the networked devices in the house and switched their security over to WPA, including the Nintendo Wii. Nearly all appliances with Wireless built-in have WPA support now (although this wasn't the case two years ago.) Everything worked, and I didn't give it a second thought.

This evening The Wife said that her ReplayTV wasn't updating its TV Guide. It's currently connected to the MN-740 and I'd forgotten to update it...when I went to set it up, I realized that this device doesn't support WPA. Lame.

I did some Googling and it turns out that the MN-740 is a dead product. However, the hardware is the same as a D-Link 108AG Gaming Adapter.

If you're comfortable taking the chance that you might brick your adapter and you absolutely void the warranty, you can do a one-way (that means, non-reversible) flash of the MN-740 with some hacking.

Follow the directions in this forum post at DSLReports (while it's still there).

You'll need:

You then need to run the Update, and while it's up, but before you hit "next" you overwrite some files using the alternate firmware. Again, you may brick your device, and you're breaking the EULA. You're on your own.

mn-740

This apparently works by changing a manifest file and telling the updater that there's a newer firmware. If it works, hook up a network cable and hit http://192.168.0.1 with admin, no password.

If it worked, you'll get the D-Link Web Administration interface, and you can select WPA as a security option.

Last disclaimer. I'm just reporting the news here. You're on your own if you choose to do this. There is absolutely no reason to except if you need WPA security on this wireless bridge.

Technorati Tags: , , ,

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

TMI (To Much Information) Networking Dialog Box of the Day

June 17, '07 Comments [13] Posted in Musings
Sponsored By

networkdiaglogbox

This dialog box is a work of art, truly. ;) It filled the screen on a 1024x768 laptop. I've read through it, completely, four times, and I'm still not quite clear on what it's trying to tell me. One day I shall unlock its hidden secrets.

First, it took me a moment to realize that the choices were meant to be clicked on. They are neither buttons nor hyperlinks. The first choice just closes the dialog...doing nothing. Apparently I'm supposed to make sure my microwave is turned off.

The second one tries to be generic by saying "The following policy" in the first hard-coded sentence. Then the last paragraph actually references BACK to the list, forcing me (rather than the computer that actually has the information) to figure out if the "policy provider identified is Windows Firewall." If it wasn't, I'm to "check the documentation." Helpful. Really. Danke.

The third and longest "not-button-arrow-choice-action-clickable-area-thing" says I should unplug my home's Internet connection. Seems a little drastic if you have a spot on the carpet to lay down all new carpet. (Also, why do we insist on calling these routers "modems"? What exactly are they modulating and demodulating. Newsflash - It's not like I'm calling out to FidoNet every night on my USR v.32bis.)

I ended up right-clicking on the connection in the tray and selecting Diagnose and Repair and all was well. I also reveled in the fact that Diagnose and Repair was NOT available when using the much more common single-left-click on the network connection icon.

Oy, the networking in Vista is SO confusing. All I can count on is netsh (how-to).

Seriously, do yourself a favor and head over to a command prompt now and run...

netsh interface ip show config

...and experience a level of detail that ipconfig /all can't touch. (Which apparently doesn't work as Admin...bummer) You'll begin to appreciate why typing...

netsh interface ip set address "Local Area Connection" dhcp

...can make you look like a superstar whilst others are still clicking around. 

Technorati Tags: , ,

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.