Projects with 31st of December deadlines should be started well in advance of the holiday vacation time crunch. To most this is blatantly obvious. Some of our peers, however, act surprised that Christmas comes on December 25th every year and that most people take time off around that time. (Some folks take a LOT of time off!) I was astonished by the number of messages I received on 12/27 regarding projects with deadlines of 12/31.
There is an ancient fable that illustrates this situation: The Ant And The Grasshopper.
Now, don't get me wrong. I am firmly in the camp that believes that ALL of IT is one team, and we all succeed or fail together. And to get even more macro, the entire company stands or falls as one. So, yeah, though it might seem otherwise, I AM a team player.
But...
But what does that say about the person who hasn't managed their
projects properly and are now looking for you to bail them out? Does
that make them a good team player? How is the greater team helped by someone who doesn't properly manage projects with cross-team dependencies? Or, at the least, ask for help prior to crunch time? Resources have to be diverted, which then impacts quality and timeliness of on-track projects.
A crisis on your part does not constitute an emergency on my part?
Now, don't be a jerk about it, but, as a manager you're going to have to decide how much you can assist at this late point in time. The right thing to do, of course, is to help your fellow human being. There are plenty of metaphors equating the corporate world as a brutal jungle, but I hope that your workplace isn't a Darwinian struggle for survival.
There is a corollary to the section title above: Poor planning on your part does not constitute an emergency on my part. The bottom line is that you shouldn't get into this situation in the first place. Plan for contingencies. Look at a calendar when you are planning a project schedule. If YOU are the one that has run out of time it's always better to admit
that you're not going to complete the task(s) at hand on time.
Conclusion
I am not claiming that I'm covering new ground with this post. I'm merely describing a management anti-pattern that seems to be popular in some organizations.
Background
This is part of a larger series of planned posts: Management Nuggets
Sunday, March 24, 2013
Friday, January 25, 2013
Rolling my own .NET 4.5 SDK
All I wanted to do was get my TFS 2012 Build Server going. (Getting the core components running was quite a struggle.) I expected some initial failed builds so wasn't surprised when I was informed of the following:
Finding the .NET 4.5 SDK didn't sound too hard to do. It wasn't, and I learned that it was part of the Windows Software Development Kit (SDK) for Windows 8. I downloaded the indicated file, which was named sdksetup.exe. Its size hinted that unfortunately it wasn't a standalone installer but (ugh) a web installer. I gave the sdksetup.exe a go on the server but wasn't surprised that it failed due to lack of internet connectivity through our proxy server. My next idea was to either extract the files that I needed locally or install and then copy the files to the server, which has worked before.
I missed it the first time around, but the Windows 8 SDK had an option to download the required files for installation to a separate computer see ('.NET Framework 4.5 SDK Tools on Windows Vista and Windows Server 2008' after the jump). This is important because- and I missed this initially as well- "The installer for the Windows SDK for Windows 8 is not supported on Windows Vista and Windows 2008 Server." Well, that's pretty cool that I can create my own installer, I thought, and away I went.
It wasn't to be. After browsing to my local copy of sdk_tools4.msi and clicking Retry, the SDK builder process gracefully prematurely ended, mentioning something about 'bad payload' or the like. Sdksetup.exe revealed an important secret at this point: a log file! Mine was located at 'C:\Users\[Username]\AppData\Local\Temp\standalonesdk'. The file was thankfully extremely verbose, and I could see all of the failed web requests for various resources.
...I searched the contents of the log file for these entries:
I then queued a build, which subsequently completed successfully.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (983): The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
Finding the .NET 4.5 SDK didn't sound too hard to do. It wasn't, and I learned that it was part of the Windows Software Development Kit (SDK) for Windows 8. I downloaded the indicated file, which was named sdksetup.exe. Its size hinted that unfortunately it wasn't a standalone installer but (ugh) a web installer. I gave the sdksetup.exe a go on the server but wasn't surprised that it failed due to lack of internet connectivity through our proxy server. My next idea was to either extract the files that I needed locally or install and then copy the files to the server, which has worked before.
I missed it the first time around, but the Windows 8 SDK had an option to download the required files for installation to a separate computer see ('.NET Framework 4.5 SDK Tools on Windows Vista and Windows Server 2008' after the jump). This is important because- and I missed this initially as well- "The installer for the Windows SDK for Windows 8 is not supported on Windows Vista and Windows 2008 Server." Well, that's pretty cool that I can create my own installer, I thought, and away I went.
Nothing too exciting initially.
I appreciated being able to deselect all of the stuff I wasn't going to need on a build server.
Ugh. More proxy issues, even locally. Shades of Mordac! I could easily download the .NET 4 redistributable though, so I was still undaunted.
Now things started to get silly. Where was I supposed to find sdk_tools4.msi? Searched Google, other folks were wondering the same thing.
Maybe I already possessed sdk_tools4.msi and didn't know it. Everything proved that theory valid. Hoorah! Now I could build my SDK installer, get the builds rolling, and move on.
It wasn't to be. After browsing to my local copy of sdk_tools4.msi and clicking Retry, the SDK builder process gracefully prematurely ended, mentioning something about 'bad payload' or the like. Sdksetup.exe revealed an important secret at this point: a log file! Mine was located at 'C:\Users\[Username]\AppData\Local\Temp\standalonesdk'. The file was thankfully extremely verbose, and I could see all of the failed web requests for various resources.
For example, when I was prompted to specify the location of netfx45_dtp.cab...
[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to send request to URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab
[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to connect to URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab
[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to get size and time for URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab
I then plugged the URL into a browser which then prompted me to download the file. After downloading, I then specified the location of the file in sdksetup.exe and clicked Retry. It took about 10 minutes or so to get all of the files. Not the most elegant of solutions but hopefully this wasn't something that I was going to have to do often.
[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to connect to URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab
[1F08:1CA8][2013-01-24T15:05:16]: Error 0x80070005: Failed to get size and time for URL: http://download.microsoft.com/download/F/1/3/[long alphanumeric string]/standalonesdk/Redistributable/4.5.50710/netfx45_dtp.cab
Finally I was finished. But would it work?
I copied my new .NET 4.5 SDK installer- and supporting files- to my Windows Server 2008 R2 build machine.
So far so good.
Looking promising.
Done!
Wednesday, January 23, 2013
Build server and the lost TFS message queue
I couldn't get the TFS 2012 RTM build server running initially. My build controller and associated agents were all stopped. The Event log told me that
I remembered reading that an update for TFS 2012 was available. Because my TFS 2012 instance is not in production use I thought that I would give the update a shot.
I apologize for the lack of tension and drama in this post, but the update resolved the issue.
Build machine [Machine Name] lost connectivity to message queue tfsmq://buildservicehost-1/. Reason: Please contact your administrator. There was an error contacting the server. Technical information (for administrator): HTTP code 500: System.ServiceModel.ServiceActivationExceptionResearch yielded some similar scenarios, but the configurations were too different from mine to be considered as viable solutions. Example: my build server wasn't using SSL.
I remembered reading that an update for TFS 2012 was available. Because my TFS 2012 instance is not in production use I thought that I would give the update a shot.
I apologize for the lack of tension and drama in this post, but the update resolved the issue.
Wednesday, January 9, 2013
Favorite Queries In Visual Studio 2012 Team Explorer
I really need to spend more time exploring Visual Studio 2012's Team Explorer. I just discovered that after adding a query to 'My Favorites' you'll be presented with a helpful summary of the number of Work Items, their State, and the type of query, such as a Flat List or Tree of Work Items.
After I made this discovery I did some research and found this nice post on many other new Team Explorer features.
Here's what it looks like:
Enjoy this ad with my compliments!
Monday, January 7, 2013
Management Nuggets: Priceless Wisdom Dispensed For Free
For better or worse I have been in IT management for almost 8 years. I haven't been fired, demoted, sued, or assaulted (yet!) so I must be doing something right. I have designed, developed, and managed projects of varying scope, from trivial departmental utilities to enterprise applications. Maybe some day I'll get around to that book I've been threatening to write for so long, but until then it's time to give back to the larger community for the greater good.
Sunday, January 6, 2013
GIGO / GINO
Introduction
Recently I was reviewing a production issue with one of my developers that involved 'bad' data from a third party application blowing up one of our proprietary processes. We do a lot of ugly 'data proctology' like this and don't have a lot of control on the front end. It is what it is. Our conversation caused me to revisit several old topics.
I'm The Garbageman
"Garbage In, Garbage Out". GIGO. It's an ancient phrase when you consider the short lifespan of computer technology. Many refute the validity of this concept. The argument is that 'bad' data shouldn't be allowed into a system in the first place, and if it does make it in then it is a failure on the developer's part. I tend to agree, and defensively program to prevent GIGO.
That being said, for better or worse, I think like a developer and so code safeguards accordingly. That means I am not thinking like an end user, and so am going to be outwitted almost constantly. I simply can't think the way that I need to in order to account for the myriad things that a user might do to a given application. (I actively practice trying to put myself in a user's shoes- remember, users are NOT the enemy.)
There are many testing techniques- automated and manual- that can also help preventing GIGO. Unfortunately, I've yet to be employed by someone who permits the time to develop comprehensive automated test suites because of the time required. Companies have slowly admitted that Quality Assurance departments offer a positive ROI, and I hope that they come around regarding automated testing as well.
I realize that QA testing was a tough sell to corporate America (and I guess the entire world's business entities), because in many cases the argument was quite academic:
The Void
Our production issue had taken us beyond GIGO into the realm of GINO ("Garbage In, Nothing Out"). Our process crashed as data was extracted from the source application. And here is where I think that we could do a better job defensively coding around the input and gracefully failing if absolutely necessary. Since we don't have a user interface- or a user!- we can't just present a validation failure message or the like. (The source application is quite deficient in the area of input validation anyway.) Fuzz testing might be one technique that could harden our vulnerable process. While this might seem like overkill, we unfortunately don't have total autonomy over how some of our processes are consumed so would need to test for a wide range of issues.
Update
I recently encountered a new variation of GIGO that involves requirements. Insufficient or overly broad requirements yield garbage as easily as bad input data.
Recently I was reviewing a production issue with one of my developers that involved 'bad' data from a third party application blowing up one of our proprietary processes. We do a lot of ugly 'data proctology' like this and don't have a lot of control on the front end. It is what it is. Our conversation caused me to revisit several old topics.
I'm The Garbageman
"Garbage In, Garbage Out". GIGO. It's an ancient phrase when you consider the short lifespan of computer technology. Many refute the validity of this concept. The argument is that 'bad' data shouldn't be allowed into a system in the first place, and if it does make it in then it is a failure on the developer's part. I tend to agree, and defensively program to prevent GIGO.
That being said, for better or worse, I think like a developer and so code safeguards accordingly. That means I am not thinking like an end user, and so am going to be outwitted almost constantly. I simply can't think the way that I need to in order to account for the myriad things that a user might do to a given application. (I actively practice trying to put myself in a user's shoes- remember, users are NOT the enemy.)
There are many testing techniques- automated and manual- that can also help preventing GIGO. Unfortunately, I've yet to be employed by someone who permits the time to develop comprehensive automated test suites because of the time required. Companies have slowly admitted that Quality Assurance departments offer a positive ROI, and I hope that they come around regarding automated testing as well.
I realize that QA testing was a tough sell to corporate America (and I guess the entire world's business entities), because in many cases the argument was quite academic:
If we hire people to test our software then we'll have a higher quality product. If we have a higher quality product then we will spend less time working on defects. If we spend less time working on defects then we will have more time to develop new features and enhance shareholder value in ACME Corporation.
But what if ACME Corp's software didn't have many bugs? How do you prove a negative like that? (That's a rhetorical question and I currently don't have the answer.)The Void
Our production issue had taken us beyond GIGO into the realm of GINO ("Garbage In, Nothing Out"). Our process crashed as data was extracted from the source application. And here is where I think that we could do a better job defensively coding around the input and gracefully failing if absolutely necessary. Since we don't have a user interface- or a user!- we can't just present a validation failure message or the like. (The source application is quite deficient in the area of input validation anyway.) Fuzz testing might be one technique that could harden our vulnerable process. While this might seem like overkill, we unfortunately don't have total autonomy over how some of our processes are consumed so would need to test for a wide range of issues.
Update
I recently encountered a new variation of GIGO that involves requirements. Insufficient or overly broad requirements yield garbage as easily as bad input data.
Tuesday, October 30, 2012
My list of Visual Studio 2012 tweaks
In no particular order, here's a list of things that I like to do to Visual Studio 2012.
Entity Framework Power Tools are worth evaluating. I haven't spent very much time with them yet, but generating a diagram from a DbContext is useful.
LINQPad isn't an extension, but is indispensable if you work with LINQ. I want to also call your attention to this excellent post on calling SQL Server stored procedures from LINQPad. I never thought that I would ever need to manipulate the results of a stored procedure call in LINQPad until today, and fortunately BillKrat's article showed me the way.
Though not part of Visual Studio, Team Foundation Server Integration Tools is incredibly useful if you need to selectively migrate portions of a project, such as Work Items only. Using the tool requires at least an intermediate level of knowledge of TFS.
- Return to the days of mixed-case menus
- Edit colors and themes
- Productivity Power Tools
- Use WinMerge as the Compare tool for TFS
- Slow Cheetah XML Transforms
- Microsoft Visual Studio Team Foundation Server 2012 Power Tools
- Git Extensions - I find myself increasingly using Git as a local repository for spike code so that I can avoid the ceremony and overkill of TFS Source Control
- SQL Server Data Tools - really handy to have installed when you want to merely run a query or examine a database
Entity Framework Power Tools are worth evaluating. I haven't spent very much time with them yet, but generating a diagram from a DbContext is useful.
LINQPad isn't an extension, but is indispensable if you work with LINQ. I want to also call your attention to this excellent post on calling SQL Server stored procedures from LINQPad. I never thought that I would ever need to manipulate the results of a stored procedure call in LINQPad until today, and fortunately BillKrat's article showed me the way.
Though not part of Visual Studio, Team Foundation Server Integration Tools is incredibly useful if you need to selectively migrate portions of a project, such as Work Items only. Using the tool requires at least an intermediate level of knowledge of TFS.
Subscribe to:
Posts (Atom)
