Jeffrey Palmero recently had a great post where defends his belief that software development is not too hard, but instead it's far to easy. While the post is great, covers a wide variety of opposing views and successfully defends it's premise, I think that he left one section uncompleted. Jeffrey begins to build a new paradigm of software developer levels that should replace the Mort, Elvis, Einstien theory that has successfully been trashed recently by Scott Bellware. Unfortunately, Jeffrey doesn't expound on the idea to the depths that I think it could, and should, be explored.

The interesting premise in Jeffrey's post is that software developers are Apprentices, Journeymen and Masters. First let us explore the definition of each title.

Apprentice: One of the definitions that I found for this title was "One who is learning a trade or occupation". An apprentice programmer could be anyone who is in the technical and/or professional infancy of their career. Apprentices require knowledge, training, mentoring and experience. We were all apprentices when we first started in the industry and, if you were as lucky as I was, you had a mentor who helped you learn technically and professionally. There are people who will never surpass this level in the industry. Those who do need passion, desire and a natural curiosity. Successful Apprentices also need to be willing to sit back and listen to other people. They should take what they hear, apply it to their daily work and always ask questions when they're not sure. Like an apprentice cabinet maker, the apprentice programmer needs to learn which tools to use and when to use them. They need to learn how to visualize what they are building, and how to apply the tools to the raw ideas and materials in a way that will result in the desired end product.

Journeyman: The definition of journeyman that I feel is most appropriate is "An experienced and competent but undistinguished worker". Journeymen (or journeywomen) are software development professionals that have learned how to use their tools, have been exposed to all aspects the software development life cycle and have the ability to take business domains and determine how to apply them through software. Journeyman programmers will continue to work with their tools, learning both the tools and the personal capabilities that they have. Although they will still need some, limited guidance, journeymen will begin to develop the skills need to become mentors. Journeymen programmers are the people that you will staff the majority of your team with. They are reliable and capable of coding moderately difficult systems. One of the distinguishing differences between an apprentice and a journeyman is professional posture. Journeymen can sit with the client and, with confidence, discuss their needs, present solution options, and assist the client in deciding which option is best given the constraints of the day. Journeymen programmers can be left to their own devices when making some technical decisions and good journeymen will show flashes of inspiration and creativity in their solutions. Like the journeyman carpenter or cabinet maker, journeymen programmers make up the largest portion or the workforce in our industry. A large number of professionals that achieve journeyman status will remain at this career level throughout there time in the industry.

Master: The term Master can be defined as "A worker qualified to teach apprentices and carry on the craft independently", but I don't think that it fully covers the breadth of skills required to achieve this level. Master programmers must be able to fully mentor apprentices and journeymen in addition to successfully implementing the most difficult technical and business systems. The full scope of a Master level programmer's knowledge is not limited to technical subjects. These programmers will be knowledgeable, experienced and skilled in estimation, business process and the software development life cycle. Master programmers are people that have the ability to schedule, coordinate and staff entire development teams. Technically a Master programmer will have extensive knowledge of their toolset and they will understand that there are other tools and that any of them may become useful. Another trait of Master programmers is their creativity and innovative solutions and designs. Like Master craftsmen around the world, Master programmers are at the peak of their career. They will be sought after for advice, knowledge and guidance. True Master level professionals are not very common. When you do work with one you will know immediately. Not only will you sit back in awe of what they do with such apparent ease, but they will also engage you in their work.

Craftsmanship
In addition to the Apprentice/Journeyman/Master metaphor, I've also touched on a craftsmanship metaphor. To me this is a very important way to define software development. Commonly you will see it described as "construction" or "building", but, to me, both of those have a cold, mechanical process to them. Software development is creative. Like a wood carver who creates a sculpture, we must create the application out of raw material. In our case that material is in an electronic form, but it is still a material. On new projects we start with nothing and we begin to chip away at the material until we have a rough shape. We don't do this willy-nilly. Now you can claim that what I just said points to a mechanical and orderly process and this is true, but only to a certain extent. Like a craftsman, we will encounter situations that we have to react to. What if, after a few days of carving, the block of wood begins to show a knot? What if, after a couple of weeks, the system no longer responds to the infrastructure? This is when software development becomes a craft. We (software development practitioners) must now use our instinct, intuition, experience and skill to determine what the best course of action is. Maybe we will design an innovative solution, but we also may determine that the issue that has arisen is a fundamental flaw. In addition to being able to solving problems with skill and experience, software development includes a component of passion. If you've ever talked to a glassblower or an artistic blacksmith about their vocation, you will be met with an endless and inspiring conversation. Although it is not as common in software development, there are practitioners that exude this same excitement and energy. The best way I've heard this put in a long time was by JP Boodhoo last Thursday when he said "Programming should be fun". If it is fun, the passion will bubble to the surface, just like it does for the artisan.

I like the craftsman metaphor because it encompasses the skill, training, experience (apprentice, journeyman, master), the creativity and the passion that I think software development requires.

I'm the Igloo Coder, and I'd like to hear about your software development passion.

Tonight we had our first meeting of the Edmonton .NET User Group and were proud to play host to Jean-Paul Boodhoo. For a first meeting, we sure packed them in (approximately 45 people) and surprisingly very few left when the Oilers' game started. I was very happy with the fact that so many of the attendees were people that I had not seen before. New face, new ideas and some great questions that really pushed Jean-Paul and even put him on the spot to justify the cost of writing 10 lines of test code for one line of production code.

With a great crowd, I was very happy to be handing out some fabulous swag. Our sponsors came through with some great books, a Visual Studio & SQL Server license and a set of reSharper and dotTrace licenses. All in all I think that we had a great meeting and hopefully people left happy and more knowledgeable.

I'm the Igloo Coder and I'm just going to bask in the glow if you don't mind. Tomorrow it's back to work.

Tomorrow marks the day that the Edmonton .NET User Group will truly come to life. For the six of you that read this blog, drop by the Milner Library in downtown Edmonton. Come for the swag and stay for the speaker if you must.

Scott Bellware's recent post Mort or Elvis? A Question for a Bygone Era is more than a rant on the inadequacies of pigeon holing developers into roles created and propagated by a group of uninspired thinkers. This post captures the raw emotional frustration that many developers have with the current state of the industry. Heck Sam Gentile even called it the best post of the year.

For me, Scott's message touched on ideas that are almost taboo to talk about. For instance, waterfall. I ran into it today at work. PM Boy wanted to enforce his waterfall schedule on the project's tester and myself. He had no ability to appreciate that two or more interations that each included test and code was going to produce better and more thorough results. Instead he was stead fast and adamant that one batch of testing and two days of coding for fixing identified bugs was all that we would do. Luckily for me, and the success of the software, I give two shits about what he thinks and whether he knows it or not we will be having multiple iterations. Why should it be so difficult to broach a subject that is founded in the idea of providing a better product?

I think that the software development industry longs for the structure of a methodology. We developers work in logic and structure all day long and are most comfortable when we are working in it. Because of that comfort level we buy into the methodology and it's structure with great gusto. We become religious zealots about the methodology and all of a sudden we've restricted our ability to be creative and to innovate.

It doesn't matter which methodology you use, if you've bought into it as the silver bullet, you will be restricted.

I'm a firm believer that no one methodology, just like no one tool, is the final answer. I like the strong specification documents that are created during a waterfall process. Not because they make it easy for me to create the software, but instead because these documents create a firm foundation for supporting the software. If you've never been a support programmer you will never understand how benefitial this information can be when you have to figure out how something was agreed to work, whether a reported defect is in fact a defect or is it a feature request, and being able to pick up the code during the hand-off from development to maintenance. I also am a strong proponent of the more "agilish" idea of always having buildable code. The flexibility that this gives you is phenomenal. I love the sense of achievement that sprints can give a team. Far too often I've worked on projects where the "sprint" was over only when the code was delivered. Sometimes that can be years in duration. If creative people have to wait that long to get feedback, they become disinterested, disenfrachised and, ultimately, unmotivated.

Which methodology do I practice? None, some and all. This is partially because I don't believe in a silver bullet solution and partially because finding training on this type of thing is almost impossible where I'm located. Yeah I can get all the information I want off of the internet, but I really want to sit down and talk with people that are full on users of the different methodology flavours. I want to be able to gather information in that fluid, old fashioned concept called a conversation.

I'm the Igloo Coder and I'm getting really stoked about the upcoming Edmonton .NET User Group's first meeting.

I've had the chance to work at a few different companies, small and large, and see both the differences in marketing and it's effectiveness. No matter what anyone tells you, marketing is what makes software companies successful or failures. It has nothing to do with the product (software) that is being sold. All a person had to do is look at the last dot com bubble and dot com bubble 2.0. It's all about marketing. Half of these sites have business models that could stand up in a first year business course at Hill Billy Valley Community College and yet they manage to get millions in funding. Why is it that this happens?

The people at these places convince the people with the money that they want, need and can't live without their product that the company is flogging. They don't sell the software, the sell the idea behind the software. If you can do that, and make sales, I think that you will have a strong start. To be long lasting you need to have the product to back up the vision that you've sold.

I've been in two smaller companies in the past and I've seen both sides of the spectrum. In one the owner/salesman/wanna-be-but-never-could-be-programmer sold the crap out of an idea. Perhaps so much that there was no chance the the software would ever be able to succeed under the expectations. In the end it hasn't, and it most likely won't (there are other reasons for this, but a big part of it is this fact). On the flip side, I worked for a company that sold their vision, and idea, but not with the unlimited hype that you commonly see in Web 2.0 style apps today. Instead they sold the "hype" in a way that the software could meet and the clients still got major benefits from it. They did this so well that they were still selling a green screen application in 2005.

The reason that I started down this idea trail was the events of the day. Today the MSDN Canada Flash newsletter came out and John Bristowe was kind enough to plug our new User Group here in Edmonton. Within about 15 minutes of the newsletter showing up in my inbox, we had received four or five emails through our Contact Us page. It was awesome to see that such a little, and very kind, plug could help the user group out so much.

I'm the Igloo Coder and if you're coming out to our meeting on the 27th of April, search me out and stop me for a chat.

Economics....like I know shite about this. I hardly passed my first year micro and macro courses, but I think I've gained a greater appreciation of these subject as I've become more aged. Mostly I have my late night, wine and food induced, conversations with friends that live out in the sticks to thank for this. More recently though, I've started to see some of the effects of economics as it exists in the real world. Okay, Alberta's economy isn't really the real world, but hell, it's my world.

So why would an isolationist like me care to comment on economics, the bond that seemingly binds us all? Well the fact is that I'm in a time an place where my skills are sought after more and more. I have a few balls up in the air right now and, although I'm doing them for the right reasons, there still are some fabulous long term side benefits. I think that these benefits will roll around and influence me in the next few months, but I'd really like to see the blokes that are working with me reap the benefits of all this goodness.

Yeah, I want to personally see the benefits, but seeing these guys succeed would blow my mind. It takes them into the real that Scott Hanselman talks about here. These guys will be able to say "Joe Blow (xxx successful project, 1 developer community created)".

How does that play into economics you ask? Well, like I said before I'm in a shoppers market. I can look for and wait for the correct situation for me. If I don't like the development practices, or I don't think that I'll be able to change the practices if I become part of the team, I can just sit back and wait a short time for the next offer to roll around. The guys I've been working on the Edmonton .NET User Group with are in the same position. They should be able to demand the situation that they desire. No longer are they the prey, they are the hunters.

What should these guys, and I, be looking for? Truthfully, nothing. In my mind we should be waiting. We need to let this fester in the minds of the companies that could possibly want our services. The longer we wait, and the greater the opportunities should be. Economically speaking we will be items that are short of supply and in high demand. It's a great combination. Low supply, high demand and an exceedingly strong marketplace. Let's see if it plays out.

I'm the Igloo Coder and I've got a 24 sided die so let's play the money game.

It's been confirmed. I am going to DevTeach in Montreal in a couple of weeks and I'm really looking forward to this for a number of reasons.

I'm really geeked up about the knowledge I'm going to absorb. This is the first time that I've been to a conference and I'm looking forward to seeing how effective the knowledge transfer will be.

The second reason I'm stoked is that I'm going to be sitting in on the User Group leaders sessions. I'm all geeked up about the Edmonton .NET User Group, and these sessions will give me a wealth of new ideas and information that I can bring back and use to grow the group here in Edmonton.

A side benefit is that I get to go to Montreal and spend some time exploring it. The city has been on my list of places to visit for some time now and I'm going to use this trip to get a bit of a taste.

I'm the Igloo Coder and if you're going to DevTeach, drop me a note and we'll hook up for some beers.

David Weiss blogs here about an impressive stack of hardware that he supports for use in a test lab at Microsoft. Yep they're all Macs...and yes you did read that right. They're all at Microsoft.

The configurations are amazing. The one that caught my eye was the IOGear KVMs putting 64 Mac minis into one monitor, keyboard and mouse. I also really like the idea of having a "hallway" between the desks. Nothing is more difficult than climbing under and over a set of desks to fix the connection of a rogue mouse cable.

I'm the Igloo Coder and you can now return to your regularly scheduled programming.

One of the big reasons that Steven R, Steve Y, Brad, Mike M and I originally picked up the idea of starting the Edmonton .NET User Group was because we wanted better meeting content quality. Steven R has been doing a bang up job, but one of the things that I've noticed is that, because we have to get our big ticket speakers from out of town, we need to have some coin lying around to bring them in. To counter act this we've got three choices. Raise the money, get more local speakers and/or do webcasts.

Until we get money in the pockets or we start getting speakers from INETA and other sources it appears that the webcast method is our best option. To do this we have to have software and licensing in place. We've looked at a couple of options including Microsoft Live Meeting and Linktivity. Both of these have the option for the webcast to include streamed audio. Unfortunately the options, for both of these products, that we have available to us don't include this feature. So if anyone out there is willing to sponsor us with a product that allows us to do webcasts with streaming internet audio (ability to record would be a bonus), please drop me a line. The same goes for anyone who knows of any free tools that will provide us with this functionality.

I'm The Igloo Coder and I'm off to cast a web in a stream.

So I upgraded to Community Server 2.0 RTM back about a month ago and since then I've been fighting to get my favourite skin (Foggy Valley) to run on my site. Every time I'd switch the skin from one that shipped with CS 2.0, I'd reopen my blog to be greeted with a "Skin Not Found" error. I've searched high and low for the cause of this to no avail. Finally tonight I was sitting around with nothing to do so I took another shot at fixing this.

My search on Google actually lead me to something useful this time. On the Community Server forums there is a thread that discusses this problem. To save you reading through all of the posts I'll summarize it here.

In Community Server 2.0 blogs there are two locations to set the skin of a blog. One is in the administration of the individual blog itself and the other is at the site level where it can affect all the blogs on the site. It turns out that there is a bug in CS whereby setting the site level skin to anything other than "default" will cause a blog that has a custom skin set for it to throw this error. So to fix the problem, always have your site level skin set to "default".

I'm The Igloo Coder and no longer do I have to look like I'm part of MSDN.

It seems that everyone has their own methodology now. It may be TDD, XP, Agile, RUP or some other flavour of the month. Last night, while I was less than sober, I had a conversation with Mike about two things that are usually last minute thoughts during the software development lifecycle: Reporting and Installation scripts.

I've built reporting solutions for years and in that time I've used a number of products including Crystal Reports, Active Reports and more recently SQL Report Services. During all that time I've also worked in companies where I've had to spec new software development and spec configurations for meta data driven applications. Through this time I've been unknowingly using a methodology that I'm going to call Report Driven Design.

During software specification we usually focus on screen design, business rules, architecture and, from these other considerations, we determine a database design. So what have we done through this process? We've figured out how to get data into a system and store that data. But what good is a piece of software that only consumes data? There are some out there that will do this, but in almost all cases business will want to gather the data, store it and then be able to extract the data in a meaningful way. I'm not sure why we regularly over look extracting the data in a way that provides business value.

One of the most powerful ways that I've found to truly understand the need, power and requirements of a system is to analyze the reports that the business users want to receive from it. This gives you great insight into the data that will need to be gathered, what the business domain terminology is, and how data may be optimally stored. More than once I've asked the business, in the very early stages of design, to provide me with mocked up reports that they would like to see the system produce. Analysis of report mockups allows me to see how the data relates to each other, which I can then use to create a logical data model, which provides me with business domain terminologies, which puts me much closer to the level of the business user.

The end result of the RDD is that I have an extremely solid understanding of data relationships, a common ground for discussions with the business users and a quick advancement into the SDLC. Now I'm not proclaiming that RDD is a magic solutions. So far it only works for me. I just wanted throw it out there so that people might begin to take reporting requirements into consideration during the design phase of their next projects.

I'm the Igloo Coder and I have to do some reporting as it seems like I was a little over quota this year.

I started listening to John Bristowe's new baby Developer Night in Canada (DNIC) today. I'm really stoked about the idea that this podcast represents. One of the main reasons for starting the newly formed Edmonton .NET User Group was to try to build a stronger community here in Edmonton. Here's hoping that we can get John to feature someone from up here in Edmonton.

I'm the Igloo Coder and I'm no longer talking about hockey.

I was out at a local establishment indulging in a few sinful liquids when the conversation turned to the fact that neither myself or my companion could identify with the new wave of methodologies. We just aren't able to see how Agile or TDD or XP are the answer to all of our development woes. None of this things, in our minds, are silver bullets for the software devleopment process. Yes there are features from each that we like, we adore or we try to implement in our development environments. We also see things that we can't use, understand or we simply don't want to try because of the situations that we're in.

For me, I love the idea of unit tests for as much of the application as possible. This stems from my last three months as a support programmer and how I hated deciding when something was fixed and when it wasn't. I also like the idea of two people working on the same code (I choose to implement this through mandatory code reviews instead of two developers at one box coding).

What we don't like about Agile and XP is it's tendencies towards continually implementing new features and being reactive to the end users every whim. One of the keys to a successful project (software development or planting flowers in the garden) is that you need to have a start point, something to work on and a concrete end point. By continually allowing additions or changes to the scope of the software development you are essentially saying "Our end point is somewhere out there". This is all well and good except for two things. One, you have no endpoint so you have no ability to say you are finished. Two, having no endpoint takes away a key motivational factor from the development team...getting finished.

For us software development boils down to this:

• You need to have a starting point (specs usually will do just fine)
• You need to know how you are going to take all that starting point data and turn it into something useful (architecture and planning)
• You need to have an endpoint to plan and strive for (completion date which is backed by concrete scope management)

These three things are essential to being successful. I've seen it done folks. You can have written in stone scope, and you can commit to a delivery date 10 months from now and yes, you can deliver solid, business ready software on time and on budget. The times I've seen this done are the times I've worked on projects where the PM can manage the three items listed above. In the end you don't need some new fangled methodology to accomplish these things. Accomplishing these goals very much are methodology and technology agnostic.

I'm the Igloo Coder and I'm thinking that blending Agile and XP might give me two developers who do yoga at their workstation.

I went to www.geekswithblogs.com tonight and found that they'd been spammed hard. Someone had setup a blog and was posting to the main feed abot cialis and other such "inflamitory" drugs. Pretty funny that a semi closed community like geekswithblogs can get suckered and have this happen.

Today I have been fighting with a problem on our new IIS6 testing environments. I've installed all the software onto the servers and then opened IIS and browsed to one of the .aspx pages in the newly installed website. Every time that I did this I received a Page Not Found HTTP 404 error. When I browsed to a .htm or .html file, that file was appropriately displayed in the browser. The next thing I tried was opening Internet Explorer and manually entering the URL to the .aspx page. Still no luck, and yes the .htm and .html pages worked just fine. I found a web service that was installed on the server and tried to open the .asmx file only to get the 404 error again.

After doing some research I finally figured out what it was. First I'll explain the software installed on the server. The box is Windows 2003 Standard Edition with IIS6, MS SOAP Toolkit 2.0 SP2, MSXML 4.0 Parser and SDK, a whole slew of Windows Updates and the Windows Support Tools. Don't ask why we have some of these things installed because I don't know the answer. I only get the box with a preconfigured build on it.

The fix. Open IIS, expand the server node and select the Web Services Extensions folder. In the Detail pane on the right hand side you will see a listing of the Web Service Extensions that are installed and their Status. In that list you should see ASP .NET v1.1.4322 (if you're running the .NET 1.1 framework) and the Status for it will be set to Prohibited. Select the ASP .NET v1.1.4322 item from the list and click the Allow button immediately to it's left. The Status will change from Prohibited to Allowed and you will now be able to browse to you .aspx and .asmx pages.

I'm the Igloo Coder and I finally able to get back into the Igloo.

You can say you heard it here first. The new Edmonton .NET User Group has formed. The user group was created with the primary goal of providing powerful speaker content, learning opportunities and technical networking to the developer community in Edmonton.

Like I said, we are launching the group. We are striving to make the meetings and events as professional as possible. Initial meetings are going to concentrate on content, but in the not to distant future we will be adding niceties (catering, freebies, etc.) as well.

I know, I know. Get to the important stuff, like what is this "content" I speak of. To launch the user group we are holding what we are calling the Spring Speaker Series. We intend to have three impressive speakers at our first three events. To start things off, the first meeting will feature Jean-Paul Boodhoo speaking on TDD and ASP.NET. For those of you that don't know Jean-Paul has recently completed two episodes on Dot Net Rocks TV and is writing a great series on using nAnt to perform builds.

If you're going to be in Edmonton on Thursday, April 27th please drop by the Stanley Milner library downtown at 5:30pm and join us.

I'm the Igloo Coder and we've got the fire stoked, come join us for some good conversation.

Jean-Paul Boodhoo is posting a great series (Part 1, Part 2, Part 3) on using nAnt to perform the builds for you applications. Since starting my last project I've become a huge proponent of nAnt, but Jean-Paul opened my eyes to an idea I had not considered.
My experience has been that nAnt is used to perform builds on a build machine either on demand or through continuous integration. Jean-Paul suggests that nAnt should be used by all developers to test their builds at their desktops. In my current environment we have nothing integrated with nAnt. No nDoc, no nUnit and no nCover. For us the use of nAnt at the desk would be to do nothing more than prove that the system compiled. We can do that, albeit slower, with F5 or Ctrl-F5 and achieve the same results....feedback on the success or failure of the compile state of the code. Now, if I were in an environment where our nAnt scripts included calls to the n*.* products, I would be all over Jean-Paul's usage of nAnt. Until I get to work in the environment, I'm going to pass on deploying nAnt to the developers on my team.
Another idea that Jean-Paul broached in his posts on nAnt was that we should be able to start a development environment with on step...getting the code from the source control system. This idea I love. Recently I had the prospect of creating development environments on a number of newly formatted PCs. One of the most tedious parts (slightly less than installing VS over and over and over) was the fact that I was going to be installing nUnit, Enterprise Library, Infragistics suite, etc, etc, etc. If I'd had the foresight to include all the binary bits for these into source control, I could have saved myself a lot of work. I also like how Jean-Paul configured the folder structure in his source control system. A folder for the solution. Inside of it two folders, one for the software you are building and the other for the binary bits. Very clean, very elegant.

I'm the Igloo Coder and I've created a BankBalance.build file, but when it runs nothing seems to change.

I found a page on MSDN that has a listing of VS 2005 Security articles and webcasts. The selection inclueds everything from Design and Deploying Secure Web Apps to VSTS: Building Robust and Reliable Software.
I'm the Igloo Coder and the igloo is currently at a threat advisory of walrus brown (a.k.a. holy crap).

I saw this post about MS Virtual Server 2005 R2 Enterprise Edition just now on Greg's Cool [Insert Clever Name] of the Day blog. Contrary to what Greg says, it is free as in beer (beer at a free beer event of course). MS really must do something about that product name though....it's just too damn long.
I'm the Igloo Coder and my host ice flow is now surrounded by a whole bunch of guest flows.

I was poking around on the internet today and I ran across this post, about some free tutorials, by Darren Gosbell. I went over to the MSDN UK site link for the .Net Framework Nuggets and watched a few. Definitely worth spending some time looking through the long list of webcasts that are available.