Geeks With Blogs
Chris Breisch   .NET Data Practices
Search this Blog!
Architecture Thoughts about Software Architecture
Don't Run as an Admin, yada, yada, yada
Jeff Atwood has a good piece on why you shouldn't run as an Admin. He even links to another good piece on the subject by Aaron Margosis. Jeff makes his point by visiting a malware website with an unprotected system running an unpatched IE 6.0. The site installed the following spyware on his machine (not that he didn't click on anything or download anything) (Quote from Adam McNeil of Webroot Software): Webroot SpySweeper detected the following spies after allowing the installer to run over night. ......

Posted On Monday, July 9, 2007 12:39 PM

Lots of Stuff on Use Cases From Tyner Blain
I've mentioned Tyner Blain quite frequently in my blog, and recently talked up their series on Software Estimation With Use Case Points. Well, if you're going to do estimation using use case points, you better know how to do use cases. Here's a good smattering of their articles on use cases. They have more. Follow the suggested reading links. The Difference Between Use Cases and Test Cases People who are new to software, requirements, or testing often ask “What’s the difference between a use case ......

Posted On Friday, May 25, 2007 9:10 AM

The Cost of GUIDs as Primary Keys
I was doing a little research for a project the other day and stumbled upon this article on Informit.Com. It's old (2002), so it doesn't even take into account new features in SQL Server 2005 (NEWSEQUENTIALID()), but does give you something to think about regarding GUIDs. This table in particular is an eye-opener: Result of Test A: INSERT of 500,000 Orders Test A Time (with 500,000 Orders) INTEGER 1 GUID 30 GUID (COMB) 1.1 To see what the difference between GUID and GUID(COMB) is, you'll have to ......

Posted On Tuesday, May 8, 2007 10:04 AM

Software Estimation With Use Case Points
There's a very good series at Tyner Blain on Software Estimation With Use Case Points. The series consists of: Introduction to software cost estimation Technical Factors of the Implementation. Primarily non-functional requirements of the system. Environmental Factors. Mostly characterizing the implementation team, but touching on process as well. Use Case Quantity and Complexity. The number of use cases and the number of steps within the use cases. Actor Quantity and Complexity. The number and type ......

Posted On Wednesday, April 11, 2007 12:22 PM

The Last Responsible Moment
Jeff Atwood blogs about The Last Responsible Moment, which involves delaying decisions as long as possible, but not longer. This sounds counter-intuitive, but I believe is a key ingredient in YAGNI. Making decisions at the Last Responsible Moment isn't procrastination; it's inspired laziness. It's a solid, fundamental risk avoidance strategy. Decisions made too early in a project are hugely risky. Early decisions often result in work that has to be thrown away. Even worse, those early decisions can ......

Posted On Wednesday, October 25, 2006 8:20 AM

Business Requirements -- The "REAL" Requirements
There's an interesting post at Tyner Blain regarding Business Requirements. Their piece is a follow-up piece to a piece by Robin Goldsmith. I find both pieces fascinating because they deal with whats and hows, two items that I find myself constantly bringing up in our design meetings whether they're with the clients or not. The difference between REAL business requirements and system requirements is not the level of detail. The difference is qualitative. Business requirements are whats. System requirements ......

Posted On Tuesday, April 10, 2007 7:37 AM

The hardest part of being an Agile Project Manager
Brian Button writes on the hardest part of being an Agile Project Manager. It is, essentially, remembering to do nothing. Ok, not nothing, but having as little direct involvement in the team's progress as possible. Why? Because you want your agile team to grow as a team, and to be, well, agile. If Brian gives them the answers to their issues, they become less an agile team, and more of a top-down team. As he says: The idea is that the team must learn to recognize the issues that they have, understand ......

Posted On Monday, April 9, 2007 12:06 PM

When Collective Intelligence Fails Us
There's a good article on the downsides of "the wisdom of crowds" over at Tyner Blain. Basically, they point out that while collaboration is good during some of the early phases of the project, design isn't one of them, because it "prevents innovative, passionate, fantastic decisions". They suggest one solution is the Apple "Dictator" approach. One way is to follow apple’s model - have a dictator. As long as the person calling the shots has good instincts, she’ll make good decisions. If she doesn’t, ......

Posted On Friday, March 30, 2007 8:40 AM

Sweet! Auto Class Diagrammer for .NET Assembly
You've probably heard of Reflector, which lets you decompile .NET Assemblies and see how they work. It's a very nice tool, for what it does. However, as has been noted by others, if you're decompiling a rather large assembly, figuring out how everything links together can be difficult. This is where something like Sacha Barber's 100% Reflective Class Diagram Creation Tool. As you can guess from the name, it uses reflection to accomplish it's task, much like Reflector does. Features: Detection of ......

Posted On Friday, March 30, 2007 8:10 AM

Big Ten Rules - Writing Stylish Requirements
Earlier, and earlier still, I blogged about this series from Tyner Blain on Writing Good Requirements. They've now surpassed the Big Ten conference and added a twelfth rule. The Big Ten Rules - Writing Stylish Requirements (no, this doesn't mean that you write them in black or whatever "the new black" is) Here they're talking about the style you use for your writing. They break it down into several categories, three of which stick out to me: Prioritize Explicitly In More About Software Requirements ......

Posted On Monday, March 26, 2007 7:36 AM

Copyright © Chris J. Breisch | Powered by: GeeksWithBlogs.net