Richard Murillo on Software Development : Visual Studio

Easy String to Resource file refactoring

Richard Murillo — Tue, 10 Feb 2009 21:47:00 GMT

During the development of internal tools we often have to stop working on features and clean up after ourselves to ensure that strings and such are embedded in the appropriate resource files and not hard coded into our applications. This can be a very tedious and time consuming process. Luckily there is a refactor extension that makes this very easy.

Resource Refactoring Tool

Resource Refactoring Tool provides developers an easy way to extract hard coded strings from the code to resource files.

Features for Resource Refactoring Tool

Works with C#, VB.Net languages. Supports all project types that ships with Visual Studio 2005 including web sites and web application projects.

A preview window to show changes.
Finds other instances of the text being replaced in the project automatically.
Lists existing resources by their similarity level to the text being replaced.
Automatically replaces hard coded string with a reference to resource entry.

More information at http://www.codeplex.com/ResourceRefactoring

Visual Studio 2008 Released

Richard Murillo — Mon, 26 Nov 2007 23:05:37 GMT

After months of waiting, I can finally say that Visual Studio 2008 was released last week. There are hundreds of new features, language enhancements, and technology integrations in this version. To help you get your head around what is new in Visual Studio 2008 and .NET Framework 3.5, get the training kit from Microsoft download center.

Some new features that I am excited about:

Visual Studio performance improvements
AJAX integration with javascript intellisense
Cider integration (WPF visualizer)
Multi-core builds
Windows Server 2008 / SQL Server 2008 support (TFS)
Vista UAC compliance
Continuous integration
Web Access
Integration of Database Edition (VSTS SKU)
T-SQL Static code analysis
SQL Dependency tree visualization
Schema reporting for documentation
T-SQL refactoring
New designers for SOA scenarios
Hotpathing (tell me where perf in my application sucks)
LINQ

Why moving work offshore fails

Richard Murillo — Fri, 20 Apr 2007 19:19:00 GMT

Not to say that all offshore projects fail, I have both been a contributor and leader in projects that have been a great success and those that have been complete failures. Each project had its own reasons for failing and were defined by the business (e.g. why are you sending it offshore to begin with) that typically include cost savings, quality, increased turnaround in deliverables, and customer satisfaction--all of which are key drivers for moving work offshore, but in doing so there are key areas your business must pay close attention to.

According to Gartner, businesses will spend more than $50 billion USD on offshore and "near-shore" outsourcing by 2007 and many projects will fail because of poor planning. Gartner also maintains that there are benefits achieved by those businesses that successfully outsource their non-core processes, however, rewards will not be instant.

Reasons for Failure

Often times, the effort and time involved in communicating with offshore team members and maintaining that relationship is underestimated. In my experiences with offshore teams to date, there has often been a lack of key items to complete awarded work effectively (like infrastructure, soft skills, planning). Additionally, coordinating between the teams requires longer hours, detailed planning, and cultural training—all of which are more expensive when working with offshore than with your own staff and can, as I have observed here, lead to lower morale and reduced deliverable output. Gartner also observes that lack of productivity in the offshore is also an issue for several reasons including high staff turnover and skill levels, especially in highly competitive markets such as Bangalore and Hyderabad, India.

Much like the dot com days, new programmers coming into the field of work are inexperienced, attaining only the necessary core skills for them to receive a job in this field and often struggle with ambiguities in specification or shifting directives. As such, the teams typically do not operate with clear processes and depend on the competence and heroics of those more experienced and not on the use of proven processes. In spite of the chaos, these teams often produce usable work products; however, they frequently exceed the budget and schedule. More often than not these teams over commit, abandon any established process in times of chaos, and may not be able to repeat past successes again.

What's more, senior executives are not involved to keep strategy on track and morale high—they are only in the picture when a significant escalation occurs or to sign a new deal. As I mentioned in my previous entry, in order for an offshore deal to succeed there needs to be a good level of communication between all parties. Requirements, goals, and expectations have to be defined clearly and in detail. Your onshore managers need to explain to the coordinating staff why the work has been sent offshore and what benefits are expected.

More often than not, the cultural differences will come into play creating havoc for the project; classic incarnations of this include not questioning authority and just pressing forward by the offshore team. All too many times do we find out late that guidance or requirements had been ignored for cross cutting to please the schedule rather than announcing a slip.

How can Visual Studio Team System help?

Gartner advises companies that plan on offshoring work to figure out their IT process maturity and identify gaps in your process. As previously mentioned, it is important to set all expectations clearly up front with your vendor. When using Visual Studio 2005 with Team Foundation Server, several mechanisms out of box enable teams to work effectively in these environments:

Process: out of the box, Visual Studio Team Foundation server includes MSF for CMMI Process Improvement Level 3 and MSF for Agile Development work item templates. By utilizing the templates and the process behind them, teams can effectively work across physical boundaries with increased confidence and transparency, allowing software development activities to be predictable and success repeatable.
Communication: Visual Studio Team System facilitates the transparency between individuals and teams with work items, a shared team portal, integrated change management, and a common data repository. The availability of information, and insight into an individual's progress, creates a more unified work environment regardless of physical location. Project managers can stay informed on an individual's progress without having to visit each individual—having real time information about each individual's work and their progress allows project managers to create precise schedules and report more accurately to management
Productivity: utilizing the common repository, managers and leads can answer common questions such as: What's in the current build that QA can test today; are requirements being met; are my teams adhereing to quality standards; is the product ready. Further, it provides the single team portal for integrating source code, issue tracking, project plans, vision statements and others that are critical assets to a project team.

Reusable MSBuild Sandcastle Targets File

Richard Murillo — Tue, 31 Oct 2006 03:24:00 GMT

Based on a past post, I have an external targets file you can place in your $(MSBuildExtensionsPath) folder (attached in zip).

You can call it like this:

</Target>

</Target>

The following is configuration from my msbuild response file:

/p:SandcastleDocumentationName=MyProjectDocumentation

/p:SandcastleConfiguration=C:\YOUR\CONFIG\sandcastle.config

/p:SandcastleDocumentationOutput=$(BinariesRoot)\Documentation

/p:SandcastleDependencies="%windir%\Microsoft.NET\Framework\v2.0.50727\*.dll,C:\YOUR\Dependencies\*.dll,%windir%\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.UnitTestFramework\8.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"

/p:SandcastleHelpGeneration=CHM

Note: tested with build 2.0.2426.28539

I'm on Channel9!

Richard Murillo — Thu, 27 Jul 2006 00:50:00 GMT

Yay!

I'm on the front page of Channel9 with an interview about using Visual Studio Team System in MSIT's Legal group.

Full link for your reference: http://channel9.msdn.com/showpost.aspx?postid=220125

Key Design Scenarios with Visual Studio Team System and Team Foundation Server - System, Application, Resource Reuse

Richard Murillo — Tue, 02 May 2006 21:26:00 GMT

In order to effectively execute an IT strategy a roadmap must be created to contain and identify what common areas exist for the business' solution that could be leveraged by other systems in the enterprise or organization; or which capabilities the solution can leverage.

Typically architects will draw their solution design on a whiteboard, and link dependant systems that way. The key problem with that is there are a number of settings and data that are required on each node that can't easily be placed on the whiteboard. In Visual Studio 2005 Architect and Team Suite SKUs architects can go beyond the whiteboard and use the distributed system diagramming tool in Visual Studio 2005.

From this diagram the architect can update how the distributed systems are defined in a solution. Opportunities for reuse can be identified and the overall distributed system architecture can be changed quickly and easily. Then, after baseline, the architect can have Visual Studio 2005 build the stubs for these services and applications with definitions and attributes set at this aggregate level. The diagram also serves as documentation for technical requirements and can be updated after the solution is though with development to represent as-built.

The key idea in all of this is we begin with the end in mind and developing our IT solution to business needs. We can use these diagrams to form views of our solution--other views available in VSTS include the system designer (a drill down into each node above), class designer (a further drill down into a visual view of the code in a system), the logical datacenter designer (provides a visual representation of the desired deployment locations), and the deployment designer (creates entire deployment plan).

As I mentioned before, it is imperative that architects identify where existing systems or their own systems could be re-used by other areas of the business to reduce cost and improve ROI. The solution design, application design, and web service endpoint design are all key to determine what resources are available and which are needed and ultimately act as inputs to those components design or re-design to suite a more generic purpose.

Visual Studio Team Foundation Server Feature Requests

Richard Murillo — Fri, 28 Apr 2006 10:59:00 GMT

I find it difficult to manage many Shared Queries in the work item tracker of VSTF. Sometimes I want to save my ad-hoc query for distribution to a small set of people (maybe just a peer even), but find no way to really make that easy except for sharing the query with the entire team. Even there, you could have hundreds of queries with no real way to group them, so you have to get creative with the naming.

Scenario: I am in a meeting and I need to quickly query WIT to respond to a question. If I do not have an instance of Visual Studio running on my laptop, I would need to start one up (alternate: MSTSC in to my primary development workstation and open a new VSTS instance there) and wait for it to connect to VSTF. Then I would need to hunt down the query, or create a new query based on the criteria, then wait for the results. After I get my results and present them verbally, Bob, a peer developer, also wants to see the results and other various details that I didn't explicitly communicate in my answer. I would have to save my query as a shared query and give him the name so he could hunt it down.

Features I want:

An easy way to share WIQL queries with team members as an external file that can be executed by anyone that has read access to the team foundation server.
- Value Propositions
  - Queries can be shared easily with users who do not actively watch a VSTF WIT database
  - Queries can be stored outside of VSTF (email, SharePoint, etc.)
    Update: this is possible in a limited fashion and is hidden away. When creating a VSTS query, you can File -> Save As... to save it as a file directly. You cannot, however, export an existing query directly to a file. You must open the query, modify it, change it back to the way it was (i.e. add a clause then remove it) then do a File -> Safe As... and save it as a file.
A way to organize the work item queries into folders and, for shared queries, adjust permissions on a folder level based on TFS or Windows security group
- Value Propositions:
  - Enhanced organization allows users to find relevant information quickly
  - Security lock down can prevent unauthorized editing of a query (i.e. only the triage team can create, update, or delete triage queries)
Functionality to search by query name, creator, last updated, etc.
- Value Proposition:
  - If my team instance has many WIT folders or queries I may need to locate a query quickly and easily
  - May wish to check for duplicate query name or search for a query that already has similar functionality that I can copy then modify for my purposes (find query from last release containing known issues and copy that to a new query so I can change the version, etc. for a new known issues query).

Goals:

Users can update existing VSTF, or create new VSTF instances and/or installations without breaking changes

IMHO if we coupled this with a command line tool that I previously proposed some users would not need Visual Studio or Office at all to manage the queries which would be nice.

gh9zRYb9z3NLEeu

Key Design Scenarios with Visual Studio Team System and Team Foundation Server

Richard Murillo — Wed, 26 Apr 2006 21:23:00 GMT

First I want to start out with some observations:

The Business expects IT to provide a technology advantage with the right capabilities at the right price at the right time
A business strategy alone is not sufficient for IT planning

Business rarely asks for IT infrastructure capabilities

Every business capability is highly dependant on the IT infrastructure

It is difficult to make a business case without a strategy except when there is obvious pain

Given that state of things most solutions are reactive and the solutions that are delivered are often tightly coupled with a business process so other processes that require similar functionality will either have to copy/paste code or build it themselves--either way it's a losing battle; we are shooting ourselves in the foot by driving up maintenance costs and reducing ROI. Then when something goes wrong we act--the entire notion of reactive maintenance and augmentation is an issue itself and this is where architecture planning and the new visualization tools of VSTS come into play.

A few of the key concepts to architecture planning revolve around clarity of business needs and IT objectives. However, more importantly IT needs to anticipate business needs to meet expectations (right solution, for the right price, at the right time). To do this we must understand our objectives and best practices to help us choose the right approach (direction and design patterns).

To understand and anticipate business needs we need to identify what capabilities the business might need for various aspects of conducting their business. Next we need to answer several key questions about those needs:

For each capability what will change over time?

Who
Where
What
When
How

Once we understand what the business needs, we can create an IT roadmap for those needs, identifying success factors, objectives, and design principles.

In the future I will publish a series of posts around the following key design scenarios:

Contract-first design
Scenario-driven design
Business process-driven design
Framework design
System, application, resource reuse
Requirements Traceability
Design patterns, guidance, prescriptive architecture
Cross-lifecycle and Team Collaboration

Strategic Architecture solutions are a way of thinking

Richard Murillo — Sat, 22 Apr 2006 01:39:00 GMT

Expanding on my previous post on accountability, fostering alignment across the enterprise is really driven from multiple angles: market opportunity, technology opportunity, capability and business operations--all which create a business strategy. In that are 5 main tenets: effectiveness, competitiveness, agility, accountability, and efficiency.

One of the key objectives of Visual Studio Team Foundation server is to create an environment where teams can collaborate and leverage past experience; this is where I think the real value of IT lies. A key item I have begun to include in my documents is that we should have multiple value propositions for each objective--a value proposition from the business and one from IT. VSTF allows us to foster collaboration and create value, but we still have to measure the effectiveness in translating business vision and strategy. Enter Balanced Score Cards.

BSCs are about clarity and turning vision and strategy into action and providing feedback on those actions. Most importantly, BSCs are more than just about profit and cost reduction, which is great, but only a segment of issues. BSCs allow for balance:

"The balanced scorecard retains traditional financial measures. But financial measures tell the story of past events, an adequate story for industrial age companies for which investments in long-term capabilities and customer relationships were not critical for success. These financial measures are inadequate, however, for guiding and evaluating the journey that information age companies must make to create future value through investment in customers, suppliers, employees, processes, technology, and innovation."

Every project has basic elements that can be used by BSCs: customers, budget, learning opportunities and growth, customer satisfaction, etc. and as such, architecture should be mapped to those elements. Visual Studio Team System Architect and Team Suite SKUs include some great visualization tools to provide a visual element to our complex systems, such as a datacenter view and code entity relationships.

In order for projects and feature teams to collaborate effectively, first they must identify which goals are shared. Those goals must then be mapped back to business strategy in a way that provides clarity. Since most human beings are visually oriented, the addition of visual views of our systems allow us to quickly and succulently (a picture is worth a thousand words) describe and recognize reusable technical areas. However, in order to successfully provide shared systems or components, one must leverage standards that exist (global, industry, team, project, etc.), focus on key integration requirements, as well as use extensibility models and OOP techniques to handle special cases. This ensures that components are developed against a clear set of goals that is transparent to everyone. Other projects then can use these views, which can be exported as images, to identify if and where the components or services provide value to their objectives during their envisioning and planning phases.

As we shift into this kind of thinking we are placing more and more emphasis on process, that is, creating deliverables consistently and reliably whether it's a process to support the application, a business-oriented process (such as a human to human workflow), or strategic planning. There are several key areas we can focus on to improve process efficiency such as having a managed workflow, minimal variation in our processes, or stakeholder/participant insight.

One key item to realize when thinking about how this architecture decision could be useful in the future is to be aware that future changes should not hurt. This can be done through encapsulation which then allow improvements to be implemented with little overall pain to the service or component itself and to other applications that are dependent on it. It is through encapsulation that you can standardize how instances of your process, component, system, service, etc. are created or invoked, and automatically test normalized user scenarios to provide quality and consistency. With these scenarios you can derive values for various metrics, such as performance, which are reflected in the BSC.

Example

You analyze a high priority user scenario and see that in the workflow there are a number of calls to your web service that reduce the responsiveness of the calling application due to the overhead of running the HTTP request and parsing the response. You then optimize this scenario by reducing the amount of fine grained calls to your service by providing a coarse grained interface to be used by calling applications.

As teams adopt these practices the organization drives toward excellence by implementing consistent best practices, optimizing return on investments (ROI), and increasing communication by collaborating, which is eased by a consistent context for exchange of information. The dependency of another application to your own forces quality up and dissolves team indifference.

Key Take-Aways

Shared components and services significantly improve communication and alignment with business objectives

In order to drive the need for dependency on a component, it must clearly communicate its value propositions and be integral to the value chain of another project
To maintain order, policies must be enforced
Each component or service has value and associated cost which can be measured using a Balanced Score Card
Each component or service can be in-sourced, outsourced, and multi-sourced
The encapsulation of business capabilities promotes
- continuous improvement
- flexible souring choices
- teaches an organization about itself