Macrocosmic Technologies

While planning the redesign of an enterprise application at my employer, we’re using the Microsoft patterns & practices Application Architecture Guide as one of our design guides.

We started by baselining the current application against the guide, and found it deficient in every single outlined quality attribute. Specifically, the quality attributes outlined are availability, conceptual integrity, flexibility, interoperability, maintainability, manageability, performance, reliability, reusability, scalability, security, supportability, testability, and usability. Unfortunately, these deficiencies are what lead to the biggest pain points, both for the business and the technologists trying their level best to deliver the optimal solution to it.

Obviously, there are tradeoffs inherent in these quality attributes. One obvious tradeoff is security versus performance and usability. All three are important in nearly every application, but depending upon the threat profile of the application, security may take precedence over nearly every other attribute.

According to the document, during the design process, the following guidelines should be considered:

• Quality attributes are system properties that are separate from the functionality of the system.
• From a technical perspective, implementing quality attributes can differentiate a good system from a bad one.
• There are two types of quality attributes: those that are measured at run-time, and those that can only be estimated through inspection.
• Analyze the tradeoffs between quality attributes.

Some of the questions from the guide include:

• What are the key quality attributes required for your application? Identify them as part of the design process.
• What are the key requirements for addressing these attributes? Are they actually quantifiable?
• What are the acceptance criteria that will indicate you have met the requirements?

TFS gives you some powerful, but somewhat obscure, functionality for undoing users’ checkouts, deleting workspaces, and more. As a TFS admin, you run into cases where a user’s workspace has become irretrievable, whether due to the user no longer being available to the project or a loss of data on the part of the user. The command for this (covered in MSDN) is:

tf workspace /delete hisworkspace;DOMAIN\OtherUser

If you want something a little more granular, you can undo the lock on a checkout, but not lose the change. This command (also covered in MSDN) is:

tf lock /lock:none $/project/path/filetounlock.cs

If you truly want to undo a checkout, losing the change, you can use this command:

tf undo /workspace:OtherUserWorkspace;DOMAIN\OtherUser $/project/path/filetowhack.cs

If the developer has moved on, whether to another project, another company, or it was their gear that moved on and took their project with it, deleting the workspace will likely work best. You don’t have to worry about unlocking their files, and you don’t have to wander all over your source tree taking care of files individually.