RyanDev.com

My favorite Dilbert strip is http://www.dilbert.com/strips/comic/2009-09-04/.  At my previous job this comic strip sums up my old boss perfectly.  He was a great guy but he never could be wrong, even when he was wrong.  He was the type of guy that would change the rules just so he could be right.  I have email after email of proof where he says one thing and then changes it later in the thread and then denies it and then will not even admit he was wrong.  It got to the point to where it was very funny actually.

I think humor really is the “best medicine” for situations like this.  We cannot expect anyone to be perfect but it should not be too hard to admit when you are wrong.  Pride gets in the way but it is even more damaging when you do not admit it because it is clear to everyone else that you are wrong and yet you continue to insist you are right.  At that point, you just look like a fool.

When I first started my previous job there were just 5 of us.  Myself and another developer would often get emails from the boss that would not make any sense or that contradicted himself within the same email.  I used to ask what we were supposed to do and the other developer would just shrug it off.  He was used to nonsense emails from the boss.

2 pieces of advice:

1. When you are wrong, just admit it.  It is not that hard to do.
2. If you have to deal with people like this especially if it is your boss I suggest you find humor in it or else you may lose your mind.

Andrew Bragdon has come up with a very interesting way of working with code.  Check out CodeBubbles.  CodeBubbles helps bring fragments of code together instead of having to open up multiple files and solves the issue of having to trace through different files when looking for something in code.

It runs on top of Eclipse so it will not work with Visual Studio but it would be great if Microsoft created a feature similar to this in the next version of Visual Studio.

I wonder how well it works with larger and more complex functions.  Either way, I believe this is a great step towards improving developer efficiency.

It is about time.  Visual Studio finally supports multiple monitors.  Most developers I know use multiple monitors as we switch between Visual Studio, email, SQL Management Studio, the Internet, etc. but now we can split code up between multiple monitors using Visual Studio 2010 and floating windows.  http://msdn.microsoft.com/en-us/library/z4y0hsax(VS.100).aspx

AgilePalooza was in Atlanta on February 26, 2010 and it was a great event.  It confirmed a lot of concepts I have been trying to push at work lately and was comforting to know the Agile community supports what myself and a co-worker have been working on.  Here are the top 5 important Agile principles, as I see them.

1. “Make sure everyone understands what they are doing and not just focusing on tasks.”  To be Agile it is important that each individual understands the goals and direction of the company and how each individual’s responsibilities fit into the company’s goals and direction.  When a Software Development company focuses on project to project and the projects are very different it is very challenging to adhere to and enforce processes because things are always changing.  However; in Agile, if everyone has a clear understanding of what goals they are working towards it makes their contributions much more meaningful and helps boost morale.  It gives purpose to the work.

2. “Agility with discipline.”  This is a phrase that was brought up often during AgilePalooza.  You cannot call yourself Agile unless you have enough discipline to stick with the processes as defined by Agile.  Some software companies claim to be Agile but really do not understand what Agile is and do not follow all of the Agile methodologies.  Just because you have a daily “stand-up” meeting does not mean that you are Agile.

3. “Predictive results come from predictive input.”  During AgilePalooza it was reiterated over and over that a continuous, well-groomed, product backlog is essential.  To be able to have predictive velocity you must have consistent and constant input, the backlog.  You need a product owner who can keep the backlog full.

4. ”Need to avoid the seagulls.”  If you are familiar with Agile you understand what chickens and pigs are.  If not, read this article http://en.wikipedia.org/wiki/Scrum_(development).  Seagulls are the people who fly in and poop on things and then fly away.  You need to manage seagulls so that they do not mess up the rhythm and velocity of the team.  The Agile team needs to remain focused.

5. ”Remove impediments.”  You must have someone who can remove impediments or else you will not be able to run an Agile team.  This can be a Scrum Master or another manager or even a Project Manager.  Regardless of who it is, someone has to have the authority to remove impediments from the team’s view.
 

If AgilePalooza is coming to a city near you I would strongly recommend attending.  It is a very small fee and you will walk away with many ideas of how to improve your processes even if you already practice Agile.

Everyone has heard of offshore development by now.  For better or for worse many jobs have been moved offshore to places such as India or China.  In America we can either be upset by off-shoring or we can take advantage of it. 

Rightshore development is offshore development done right.  I will not recommend any specific offshore development companies; however, I will provide some tips as to what to look for and how to turn offshore into rightshore with respect to software development.

Find a company who practices Scrum- Why is this important?  The foundation of Scrum insists that the development team is self-managing.  Since your offshore team will be in a different country and likely a different continent you need a team that does not need handholding.  You need to feel confident handing over a set of requirements or tasks to your rightshore team that they will complete them successfully and accurately without requiring too much of your own time. 

See the Scrum Alliance for more information on Scrum.

Low Turnover-Select a company who has a low turnover rate of software developers.  You want to have a core group of developers which learn to understand your business and your company culture and if you are having new developers rolled in and out of your rightshore team you will have to continually battle the learning curve.  A rightshore development team should be an extension of your own core team within your company.

Version Control- Version control is critical when transforming an offshore team into a rightshore one.  It is imperative that you always have the latest copy of source code your rightshore team is working on.  You need to review their code and make sure it adheres to your standards and policies.  It does not matter if you have a single source code repository or if you manage 2 different repositories as long as your processes ensure collaboration between both teams.  It can work very well if there is a single source code repository from which both teams checkout their code to work on.  An alternative is to allow the Scrum, self-managing, rightshore team to have their own version control from which they do their own QA and when they send updates you can check them into your own source control and perform your own QA. 

Microsoft Team Foundation Server- It is essential that you have a single location to store your backlog of to-do tasks.  I recommend Microsoft Team Foundation Serverand the Agile project template.  Here you will record your to-do tasks, referred to as sprint backlog items and product backlog items.  You will assign tasks to the appropriate team and even team member if desired.  You will track ETAs, bugs, and progress.  Microsoft TFS provides a central location to store discrete tasks from which developers can work effectively.  You can also have a list of assigned tasks sent to each developer each day.  Go here for more information.

Communication Skills- It is imperative that the company you chose assigns a project manager who can communicate in English and has a lead developer who can effectively communicate in English.  It is not necessary for all team members of your rightshore team to speak or even understand English.  It is critical; however, that the lead developer can effectively communicate, both orally and in written format, to ensure that your business needs and the design goals are being fulfilled.  You should have frequent (daily) phone calls to discuss open issues and allow for a dialogue to resolve questions and concerns.  You will need to make sure information is repeated to ensure both parties understand each other accurately.  Some offshore companies charge more for developers who can speak English and you must be willing to make the investment.  Poor communication between teams will kill any project.

Consistency- For an offshore team to become a rightshore team they must provide consistent and reliable code.  It is important to maintain the same members as is feasible so that you can rely on consistency.  You have to be able to pass on projected completion dates of tasks to your client based on the ETAs the rightshore team provides you.  You need to have confidence that their estimates are accurate so you can accurately estimate to your client or know how much to buffer your estimate.

Identical Environments- You do not want to spend time hunting down bugs after your rightshore team has provided working code only to find out that a difference in your environment is the root cause of the bug.  You need your environment and the environment the rightshore team is developing in to be identical, at least as much as is possible.  The best way to do this is by using virtual machines.  You create a development environment on virtual machines in which you will work and then you send your VMs to the rightshore team.  This way, both teams are working off of essentially the same systems.  If possible, the rightshore team should remote into the same environment which your team uses but often due to geographical distances and locations that may not work well.

Some have tried to go with the cheapest outsourcing companies and doing so will not result in a solid, useful, and successful project.  As the saying goes you have to spend money to make money.  If you follow my suggestions you will find there are companies who can deliver on each of these points and still at a price point which allows you to realize desired profits.

I have already posted the SQL code you can use to get a list of all open work items across all projects within Team Foundation Server 2008 (TFS).  Now I will walk you through one way to create a SQL Reporting Services Report using Microsoft SQL Server 2005’s SQL Server Business Intelligence Development Studio.  Then we will see how to schedule it.  Note: We will not cover how to configure SRS.  This is assuming that SRS is already setup with email settings.

This sample was created directly on the Microsoft Team Foundation Server.

1. Open SQL Server Business Intelligence Development Studio

2. Click Create Project.  There are several ways to create the report and in this example choose the template named Report Server Project Wizard.  Provide a name of TFSItems and save the project anywhere.

3. The Welcome to the Report Wizard screen is displayed.  Click Next.

4. Create a new data source and name it dsTFSItems.  Click Next.

5. Click Edit and provide connection information to your SQL server.  Set the database to TfsWorkItemTracking.  Click OK.

6. The data source connection string is now filled in. Click Next.

7. Copy and paste the SQL statement from my earlier post.  Note: you will probably have to correct the single quote characters because they will probably not paste accurately and you will get syntax errors when clicking on Next.  Click Next.

8. Select the Tabular report type and click Next.

9.  Move all of the fields into the Details section.  Click Next.

10. Choose a table style.  In this case, I chose Slate.  Click Next.

11. Make sure the report server field is correct.  Leave the deployment folder with the default value.  Click Next.

12. The final screen of the wizard is displayed showing a summary of what the wizard will do.  Click Finish.

13. You now have a TFS report in Visual Studio.

14. We want to be able to select a specific person and see just the tasks that are assigned to them.  To do that we need to have a second dataset.  Click on the Data tab and then under Dataset choose <New Dataset…>

15. Name the dataset dsAssignedTo and paste the following SQL into the Query String field.  Note: You may have to adjust the single quotes after pasting.

SELECT Person, Email FROM TFSWarehouse.dbo.Person WHERE Email IS NOT NULL AND EMAIL <> ” AND EMAIL LIKE ‘%@%’ ORDER BY Person

16. Now we need to add a report parameter.  To do so, click on Report, Report Parameters in the menu.

17. Create a report parameter named AssignedTo and select from the dsAssignedTodataset as shown below.

18. Now we need to use this report parameter in our main dataset.  Select the dsTFSItemsdataset and add one more WHERE clause: “AND w1.[Assigned To] IN (@AssignedTo)”

19. The report is done.  We now need to deploy it to the SRS server.  To do so, right click on the project name in the Solution Explorer and choose Deploy. 

20. Likely near the bottom of your screen will be the Output window and it should indicate the deployment was successful.

21. Now, open Internet Explorer and browse to the report server at http://localhost/Reports.  You will notice a folder named TFSItems which was created when we did the deploy. 

22. Open the TFSItems report folder and you will see the report we created, TFSDailyItems.

23. Click on the report and you will see that we have a drop down list of various people in TFS. 

24. Select a name and then click on View Report and you will see their open items.

25. To schedule this report, click on the New Subscription button.  Fill out who you want the report sent to and how often.  Then select their name from the AssignedTo report parameter.

26. To see which subscriptions have been setup, click on the Subscriptions tab of the report.

That’s it.  Now every day at the time you specified an email will be sent with their open TFS items from all projects.

I have been playing around with a way to have Microsoft SQL Server Reporting Services (SRS) send a list of open items from Microsoft Team Foundation Server 2008 (TFS) to anyone who has open assigned TFS tasks within all projects.  The database structure is not entirely clear nor does it appear that there are stored procedures to retrieve this information.

While doing SQL traces I discovered that TFS uses in-line SQL statements and builds dynamic SQL statements instead of executing stored procedures.  As such, I have tested the SQL statement below and it appears to work correctly.  One thing I am struggling with is any project created using the eScrum template.  It does not store Areas and Iterations of Sprint Backlog Items the same way.  If you have figured it out, please post a comment, and I’ll take a look at it some more later.

Often when writing XML files to disk as text files developers do not include any formatting.  As such, if you need to open the file and examine it in Notepad, for example, and make changes it may be very hard to read.  There is an easy way to fix this.  You can download the executable file hereor just use the following code in Visual Studio.  NOTE: This is a console application expecting a file name as a command line argument.  You can drag your text file onto the executable file and a new file will be created with the same name as the file name with “-formatted.xml” appended.

When you have a SQL Reporting Services report developer who is developing reports on a different Microsoft SRS server than where you are deploying the reports it can be very common to get this error: “The report server cannot process the report.  The data source connection information has been deleted.  (rsInvalidDataSourceReference)”

A developer’s first instinct may be to open the report in Visual Studio and make sure the data source is set correct and even possibly deploy the data source and the report again through Visual Studio to the SRS server.  Unfortunately, this often does not fix the issue.

There is; however, an easy fix to this.  There is a GUID stored in the rdl file for the data source. Since the developer is working on a different install than the production server the GUIDs are different.  There are ways to overcome this, such as create the production server and then use a backup of it to develop on, but I will not get into those details now. 

You need to use the SRS web interface to resolve the GUID issue.  Refer to the following screenshots.

1. Go to the Properties tab and you will quickly notice the problem in red.

2. Click on Browse and expand the tree under Data Sources and select the correct data source and click OK.

3. Now, a very important and easily forgotten step, click Apply.

That should be it.  It has updated the report to point to the correct data source with the correct GUID.  Click on the View tab to see your report.

Here are some quick and easy to use tutorials if you are interested in learning VBA.  Please let me know if there are other topics you would like me to cover.  There are 6 modules and each has a series of attachments to download the full documentation and code samples.  Below are summaries of what each module covers.

Module 1

Introduction

The purpose of this module is to familiarize you with the Visual Basic Editor environment and to introduce some coding techniques. By the end of this module you should be able to accomplish the following tasks:

• Arrange and navigate the Visual Basic Editor
• Write and edit macros
• Write code to respond to events
• Recognize and have a basic understanding of the Object Model

Attachments: Module 1.doc

Module 2

Introduction

The purpose of this module is to introduce automation of Microsoft Office products. By the end of this module you should be able to accomplish the following tasks:

• Automate one Office product from within a different Office product
• Understand how to reference the Object Model of different Office products
• Use debugging techniques
• Implement error handling

Attachments: Module 2.doc; DataFile.xls

Module 3

Introduction

The purpose of this module is to allow you to put in practice lessons from Modules 1 and 2. Each of the examples listed here come from real calls that I have had. By the end of this module you should be able to accomplish the following tasks:

• Write custom functions in Microsoft Excel
• Play a sound in Excel when a cell changes
• Format cells in a Word table

Attachments: Module 3.doc; Count Criteria.xls

Module 4

Introduction

The purpose of this module is to introduce user forms that can be used in VBA. By the end of this module you should be able to accomplish the following tasks:

• Create a user form in Excel.
• Create a user from in Word to pull data from Access.

Attachments: Module 4.doc; Count Formulas.xls; Addresses.mdb

Module 5

Introduction

The purpose of this module is to introduce VBA programming with Microsoft Access. By the end of this module you should be able to accomplish the following tasks:

• Create a new Microsoft Access database from within Excel.

Attachments: Module 5.doc; Addresses.mdb

Module 6

Introduction

The purpose of this module is to introduce VBA in Microsoft Outlook and Microsoft PowerPoint. By the end of this module you should be able to accomplish the following tasks:

• Create a user form in Excel.
• Create a user from in Word to pull data from Access.

Attachments: Module 6.doc; Addresses.mdb