My experience with source control and team management tools has been fairly limited over the dozen years I have developed professionally. Being primarily a Microsoft developer, I have worked with more Visual SourceSafe than I'd like to admit. Since the late 90s, I've felt VSS was always a ticking time bomb, and it has burnt me on some really bad occasions way back in the old Visual Studio 6 days. Outside of VSS, I've had my fair share of Subversion on side projects and open-source development and more recently quite a bit of Git and some Mercurial. But somehow, I've never messed with Team Foundation Server too much. That changed over the past two weeks after watching some demos of Team Foundation Server 2010 RC and really liking the workflow of Sharepoint, Visual Studio, and the reporting. I know there are automatically people that will dispose of this because it's Microsoft, but it seems like the integration with all facets of development and planning have been solid from what I've seen so far and I'm currently implementing TFS2010RC into our group. I'm at the very infant stages of the deployment now and thought I'd explain the environment I'm in and my reasoning behind pursuing this solution.
I've gotten to a point in my career that I think most people who aspire to be great developers reach at some point, where I look back on work I've done and the daily work I currently do and realize things have to change. Nearly all of my jobs I've ever had were the "react to fires" type (including my current position). Meaning that, there is a "plan" of what you are supposed to do or what the management wants you to do, but there is also the element of support. Unfortunately, it seems like a vast majority of my day is context switching (which is a proven killer of productivity) between supporting well over two dozen random applications and trying to complete new development objectives. My group has lost some resources over the years and it has just gotten so out of hand, that I felt like I had to take action…somehow. I think 90% of the developers out there are in a situation like this. I've not personally met too many programmers who get to work on nothing but new development all the time or are shielded from brownfield applications and support. Maybe I'm just unique in picking jobs that require this sort of thing? I'm not sure.
So, specifically, the way support and requests work in my group is that a person representing one of our user areas, like a supervisor for example, will send an email to our support email distro saying "this is broken", "please setup this new user or resource for application x, y, or z", "please add this new feature to this application by yesterday morning", and so on. It is very low-tech and you find yourself watching your inbox much more often than you should be. I've been trying to come up with ways to handle this better, but the fact is we have nearly one hundred documented applications our group supports and over five hundred users across those. It's not as easy as some places where I've been that have 10,000 users on a single system or something like that. To compound things, we have a range of technology spanning back to classic ASP and some VB6 up through C# 3.5 windows forms. It can be tricky at times to be cranking away on a new ASP.NET MVC 2 app and have to drop it to figure out why something isn't working on a classic ASP page and remember weird things about VBscript and discover the code hasn't been touched in seven years and the sight of unclosed table tags makes you panic. I could go on and on, but you get the point. What am I doing to cure, or at least calm, the problem?
The good news is that my direct management is great. They trust me and the team to use our knowledge and skills to determine the tools, technology, and methods to deliver the best possible solution to our users. The environment is the extreme opposite of micromanagement. When I recommend a new tool or a solution I want to try, its never been met with resistance, as long as I have done my homework and present the pros and cons. I am lucky in that respect.
I started the improvement process about five months ago by building some infrastructure tools to monitor our servers to map out things like IIS virtual directories, databases, and finally usage on our applications. I then integrated all of these individual tools into a centralized web-based application with some simple charting and dashboards. This has helped a lot in determining exactly what we support and a better way to evaluate what our users are actually using and not using. After gathering this data and breaking it down, we've been surprised in some cases by small applications that actually were used much more than expected and, on the other hand, some of our high-visibility applications are used very much and require solid change management to not accidentally push a bad build out or something else that would cause an outage.
I moved from the data gathering phase and polishing of our internal monitoring tool to implementing a continuous integration server with our Visual SourceSafe repository. I focused on a few key applications and had builds triggered in JetBrains TeamCity (great product) and really learned a lot about MSBuild, Nant, and automating things like deployments, test coverage, FXCop, and other ways to ensure code quality with little to no hit in team productivity. If nothing else, it made us more aware of how poorly we were setting up new projects in Visual Studio. Just the fact of getting an application to build on a CI machine automatically makes you realize how important it is to know the inner workings of your build tools. Especially when it comes to dependencies. It was a great learning process and I encourage anyone who has read this much to absolutely setup a CI "server" (I used an extra development PC for ours). TeamCity isn't the only one out there in the .NET world, CruiseControl.Net and Hudson are two free, open source ones that come to mind.
Just implementing continuous integration on a few applications was a great first step, but it still didn't solve the main problem of "what in the hell are we doing each day?". We didn't have a major issue with pushing out bad code. But we still didn't know who was doing what, why, and for whom. Honestly, from an organizational standpoint, our group does enough and works fast enough to make our users happy. That is great and I'm sure most people would come to work each day just fine with that. But I still feel like there is too much effort going into just keeping on top of what needs to be done now, what can wait, and what can be put on hold. We need some sort of way to manage and understand this and the first step to stopping the bleeding, in my opinion, is logging and keeping track of what is going on. I like to compare it to money management. If you are constantly running low on money each week, you need to track you spending for a period, analyze the data, and make adjustments. But for som
e reason, people in the software world will just keep going back to a chaotic work environment for years and not look at it this way. Nothing ever fixes itself and you can always say, "I'll go back and make a better admin screen for that application when I have more time", but I'm telling you… "more time" will never come.
I thought about building a simple task management tool into our internal application tool that would link what pending tasks I have to an individual application. This would at least help me stay organized for myself and also would allow me to provide a report or dashboard in the utility so my supervisor could easily see whats on my plate. However, I'm 25% done with a conversion of this tool to ASP.NET MVC and actually trying to remove features and keep it simple. Adding extra database tables for something like task management seemed to be counter-intuitive at this point, with our backlog of work. I've tried using the task management built into Outlook, but I spend too much time in Outlook already. Mostly reading support emails (not related to anything I support) or blocking my calendar off from meetings I want to avoid.
There are a ton of task management options out there, including something as low-tech as index cards or a whiteboard, excel, or a web application. A number of free or really cheap (small monthly fee) tools are available online. A lot are hosted Ruby on Rails apps, which are great for organizing team development. I seriously considered pitching a solution such as this to our group, but the thing it lacked for me was integration with our source code. Its fine to manage your backlog or tasks in a tool outside of your source code, but when I make changes to code and commit them, I really felt there had to be a link to better answer "why did you just change this?". Yeah, you could make a comment, but I really wanted it to be an integrated solution. This led me to Team Foundation Server.
I spent some time looking at TFS2008. I requested an upgrade to my MSDN account to the Team Studio level and planned to go down that road. But with TFS2010 and Visual Studio 2010 less than six weeks away, it made sense to look at the new stuff. I watched some videos online and downloaded a virtual server image and really enjoyed it. I love the Sharepoint portal TFS sets up and the task management seems decent. Some portions feel overly complicated to the simple web-based solutions mentioned earlier, but considering everything was integrated in the development IDE, it made sense. I should also note that I'm actually not a huge Sharepoint fan at all. But, at a corporate level, its huge where I work. Every department is now using Sharepoint for their internal sites and a number of people in my group have been sent to Sharepoint training. So, I have to swallow my few issues I have because I know the fact that it is a familiar interface for the management types will be a big selling point.
So far, I've gotten my TFS2010 server setup and configured with reporting services, data analysis services, and reporting services. I am launching a new development project (VS2010 WPF application) this week using the agile templates and will begin populating my work backlog and training some others on using the portal, accessing my task info, and figuring out best practices in regards to the source control. Things like branching code will be a whole new concept for people at my company, for example. I have a lot to learn and it should all be an interesting process.
My point in writing this isn't so much about the tools or specific issues I'm dealing with, but the attitude I've taken over the years of just ignoring the bad workflow or assuming things would get better on their own. If you are in a similar situation and are tired of it, make a change. Don't worry about management or pushback. Do your research and start small. There are free tools out there to achieve less friction when it comes to managing your projects or tools to improve your development. I invested a lot of my own time after hours to create my internal monitoring tools. I know a lot of people think its dumb to work for free at home, but considering you spend a majority of your adult life at your job, it makes sense to make changes that will make your life easier. If that means giving up a couple hours at night for a few weeks to automate some aspects of work and build a couple new things, I'm willing to donate that time. It has paid off. I will warn you, though. All of these little wins have made me absolutely obsessed with pursuing larger change. It's been a lot of work, but it feels good to realize that I can make a major difference in my daily job and my career. Isn't that what most people want the ability to do?
I kinda feel like this long, rambling post just died all of a sudden. I think, as I was wrapping up, I realized there are some valuable things I did learn last week while setting up my TFS server and it makes sense to share those items in future posts. I will start drafting up some blog posts in the next few days on things I discover working through this implementation.
Post a Comment