Friday, May 28, 2004 This week at TechEd, Microsoft announced Visual Studio Team System. It includes a number of features to get development team more into the life cycle such as unit testing, profiling, and code coverage. Sounds exciting but a couple of things I have read bother me.
Class diagraming will not use UML. Instead Microsoft has created a new notation which Microsoft says is needed to support two-way application design. The other point that I read that worries me is that Visual Studio Team System integrates tightly with SQL Server 2005. My assumption here is that as a team tool the database used most likely has to be a centralized database accessible by all team members. However, this is just an assumption at the moment but as a developer who uses a laptop and one who does development disconnected from a network from time to time such as when flying, I wonder how this will change the development experience or worse how it will limit the development experience. Guess I will have to wait until I get my hands on the bits to see what will happen. posted by Kirby | May 28 11:00 AM | comments (0)
Thursday, May 27, 2004 Here's a fun game to play while walking the streets of New York, hipster bingo. posted by Kirby | May 27 02:31 PM | comments (2)
Wednesday, May 19, 2004 I'm currently working on a customer project with 16+ VS.NET projects in a single VS.NET solution file. The single solution file is handy in that all the source code that makes up the complete customer solution is available in one place. The solution includes multiple C# projects, unit test projects, database projects, and one Reporting Services project. Also our build environment relies on NAnt scripts so each project that produces an assembly also has its own .build script.
A single solution approach is nice because I have access to everything that makes up the solution, from build scripts to C# source code to stored procedures. But finding the right project or file is becoming more challenging each day as more is added to the solution. This is where Enterprise Template Projects comes to the rescue.
An Enterprise Template Project is a project type available in Visual Studio.NET Enterprise Edition or greater, and it can contain any type of file including other project types. I started out by creating a set of enterprise template projects that represent the grouping I want. For example, I created template projects with the names Applications, BusinessServices, Databases, Frameworks, NAntScripts, and UnitTests. Within each of these projects I added the appropriate reference based on the grouping to existing project files. UnitTests contains references to the C# projects responsible for producing our NUnit unit test assemblies. BusinessServices contains references to projects that make up the middle tier of the solution. Framework contains references to framework projects, and so on.
NAntScripts is interesting in that it does not contain a reference to another project but instead it contains references to .build scripts files found in other projects. I like this because many times when I am working on the build scripts I need to modify more than one script. Before making the grouping I was jumping from project to project in search of the .build script file. Now I have references to all the script files in one place making it easier to find a particular script file.
With this new grouping I am able to more efficiently find the projects and files I need to work on. The grouping has proven itself to be a huge time saver for me especially when working with large single solution files.
One additional note on using enterprise template projects to organize your single solution: To prevent scattering .etp files throughout project directories containing the source code I recommend creating a single directory that will store all of the .etp files. References within an enterprise template project do not have to fall under the template project. Instead files referenced within the .etp can be stored anywhere on the hard drive. This means the .etp file does not have to dirty up the project directory where the source code actually resides.
posted by Kirby | May 19 07:20 AM | comments (0)
Tuesday, May 18, 2004 Don't be a "Cargo Cult" Programmer (or don't get bit by the "Law of Leaky Abstractions") posted by Kirby | May 18 06:24 PM | comments (0)
I have been working today on stabilizing our build environment for a customer project. NAnt has been a great to so far for this. But today I wanted to start running NUnit tests of our assemblies from the NAnt script. I have tried a combination of Xml in attempts to get the NUnit task to work as expected. All assemblies except one have a configuration file so I must use the
Say I have 4 test assemblies. 2 out of the 4 may load. The other two seem to be ignored. The
posted by Kirby | May 18 05:45 PM | comments (0)
When did the term code monkey become inappropriate in the office?
I was talking with a programmer who is employed by the customer yesterday and a question came up about coders. This lead to a conversation about the meaning behind terms like "coder", "programmer", and "developer". All can be the same while having some differences. During the conversation I mentioned the term code monkey. The programmer I was talking to never heard of the term so I showed him the definition of code monkey from The Jargon Dictionary.
Later that day the GM from my employer talked with me about the term, and 15 minutes later I got an e-mail from our HR Generalist requesting to talk with me about this. Apparently code monkey has become an offensive thing to say, or at least it has within the walls of my employer.
I see nothing wrong with this phrase. I have even considered myself a code monkey from time to time. Last summer I was on a project for a customer where I got to be a code monkey and I loved it. It was one the best project I have been on since joining my employer.
The whole situation reminds me of an episode of Recess called The Story of Whomps. The school principal and one of the teachers deem the word "whomps" as a cuss word and set out to punish the kid who created the word. The scandal goes all the way up to the Board of Education. When the superintended learns the scandalous word is "whomps" he says something to the tune of "Anyone who hears something vulgar in the word 'whomps' has a vulgar mind." And that's how I feel about the term code monkey. If you hear something offensive in the term code monkey than you probably have an offense mind.
posted by Kirby | May 18 08:42 AM | comments (0)
Thursday, May 13, 2004 Amazon has some great prices on MSDN Universal subscriptions. A first time subscription is only $2399 USD saving more than $400 USD over Microsoft's price. The upgrade price is $1974.99 USD. I think these prices are for U.S. customers only.
posted by Kirby | May 13 09:16 AM | comments (0)
Friday, May 07, 2004 The PInvoke.net Add-in for Visual Studio.NET will insert PInvoke signatures into your code. What's cool about this is that the add-in retrieves the PInvoke information from the PINVOKE.NET wiki. And you can contribute signatures back to the wiki from the add-in. What a neat idea. posted by Kirby | May 7 12:45 PM | comments (0)
Joel Spolsky has posted his foreword to Mike Gunderloy's new book, Coder to Developer. The foreword puts in very simple terms what it takes to be a software developer, which is more than knowing how to writing code. As Joel puts it, a software developer can "take a concept, build a team, set up state of the art development processes, design a software product, the right software product, and produce it." I'll add that a software developer should understand various development methodologies and how to apply them, and the importances of QA and testing even though these are assumed to be part of the state of the art development process.
The interesting thing here is that a software developer still does not know it all, and a good software developer knows this. A software developer will take lessons learned from past experiences, and will enhance and improve on those experiences for future project. The good software developer is always learning. Much of the learning comes from hands on experience, which I personally believe is very important, while lucky ones will also learn from more seasoned software developers who are willing to coach and mentor.
I find interesting though, that in my field of work there is the large number of individuals who think they know software development but don't know the first thing about being a software developer. These individuals think that because they know how to write code they know how to develop software. I know how to drive a car but I don't know how to build a car. Nor do I think I know how to build a car. But many in the software development world think because they know how to write code they know how to build software. The truth is these individual do not get software development, which can typically results in a poor quality product, a product the does not meet the needs of the users, or even worse a product that never sees the light of day.
Being a software developer is more than writing code. Being a software developer is knowing how to bring a concept to life within the computer through software and code, applying the right techniques and processes, ensuring the maintainability for increased life expectancy of the product, selecting the right set of tools for the job, building a team right for the project, and ultimately producing a quality product that meets or exceeds user expectations.
posted by Kirby | May 7 11:07 AM | comments (0)
Take a virtual tour of Bill Gates' estate. posted by Kirby | May 7 09:16 AM | comments (4)
Thursday, May 06, 2004 MSN Careers - Avoiding Burnout - Career Advice Article: "Avoiding Burnout" posted by Kirby | May 6 05:49 PM | comments (0)
Saturday, May 01, 2004 This sounds like fun. I'll have to check it out this Saturday.
posted by Kirby | May 1 02:12 AM | comments (2)
