Do you have a “Calling” or a “Job”?

I am almost done reading “The Happiness Advantage” by Shawn Achor. In it he talks a little bit about how people view their jobs. Regardless of the job, whether it is a janitor or a CEO, if you view your job as your “calling” then you have a tendency to be more successful at it (success is based on your own criteria).

So I started thinking about what I do and why I feel I am successful at it. First, what is success to me? Well, success to me is a combination of things. It is me looking forward to getting up and going to work everyday (well almost everyday), it is displayed to me as my customers (those folks inside Burt’s Bees at the moment) thankfulness for me solving a real problem, as my work having a positive financial impact to my company, as me being able to spend quality time with my family and enjoy a life outside of my work.  These are my primary criteria and indicators of success.

So lets match my criteria for success with the last year here at Burt’s.

As an Agile Software Development Coach and a Software Engineer my job is to guide others through a methodology that I am passionate about and to demonstrate to them its effectiveness by participating in it as an engineer. I love what I do! And I love the group of people I do it with! We really enjoy our work day. We laugh a lot and swear too much, but we get work done and our customers are generally pleased with our work.

The last year has seen two clear victories for the Agile methodology here at Burt’s. Two projects where the business came away happy and the application development group came away proud of what it produced. I credit the business for being open to Agile and the team for working hard at making it work.

We believe our work has a positive financial impact on the company (we have also been told this by those who would know). We can see the time saved in not having to discern certain data points, in being able to add data points to the ERP without much effort and using those points to make strategic decisions. Great indicators to the application development team that our efforts are paying off.

We also are able to work from home when we need to. When my daughter has a gymnastics meet out of town, I don’t have to beg and plead to get the time to go.  When my son has a soccer tryout at 5:30pm 45 minutes away through Raleigh traffic, I can leave early to get him there. When my wife and I want to spend time helping a refugee family during the day in Durham with our church group, I am given time to do that. So my life outside of Burt’s is a blessing and I am happy to be able to have one.

Do I feel my job is my “calling” as Achor talks about in his book? You bet! Do I think I am more successful as a result of my attitude or does my attitude stem from my success? Well, I believe my attitude contributes to my success more than my success contributes to my attitude but each case is true.

In my previous “job”, I felt I was successful to a certain extent but I did not see it as my “calling”.  It did not hit all of the criteria I outlined above. Some things were missing. Which is one reason why I left to find my “calling”.

What is your “calling” and are you doing it?

Till next time…

Technorati Tags: Software Development,Agile,Coach,Engineer,Methodology,Durham,Attitude

Auditing ExtendedProperties

So yesterday I was coding a User Story about reporting audit information for the project I am working on.  This project basically extends the ERP application called Macola (don’t get me started). What we are building is an extended properties application and we are auditing each change to an extended property for SOX compliance.

So we are using a class called (funny enough) ExtendedProperty. We have a collection of these objects to fill our grid using a List(of ExtendedProperty).  We were auditing each save in the Save method of each individual ExtendProperty.  This created a ton of audit entries in the database. We decided to combine these into a batch audit at the collection level to mitigate the number of entries and use the xml data type in SQL Server.

So our Audit objects began to take shape and now look like this:

An AuditEntry has a one to many relationship to an AuditChange. And an AuditChange has a many to many relationship to AuditColumn as well as AuditKey. Each of the objects overrides the .ToString function to return xml to be stored in the database.

The metadata in AuditEntry is in separate columns in the database and AuditChange, AuditColumn and AuditKey are all stored in a single xml column.  This gives us great flexibility in what we can audit and how much space it takes up.

How this relates to an Extended Property is that each property is responsible for its own audit unless it is in a collection of changes.  So we had to change how we accessed the List(of ExtendedProperty) in the containing class. We could not have a List anymore because it became difficult to act on that list as a whole. This caused us to create an ExtendedProperties collection class that inherits from List(of ExtendedProperty). This class gives us the ability to act on the collection as a whole but still allows us the functionality of a List(of T).

The results of this audit can be returned flattened using xquery in SQL Server.  It can be a little complicated when trying to compare values (sql:parameter(“parametername”) is your friend in xquery). But it makes life easier when batching audit entries.

Cool Visual Studio 2010 feature

As an aside, while I was coding the audit classes above I discovered a GREAT feature in VS2010. First I created a file for the class, then I started coding the public properties of the class. I did not create the constructor of the class yet.  I went to a calling class and instantiated this new class and put the arguments in the call.  There appeared a blue squiggly line below the code with the little red block in the bottom right.

When I click on the little red block it tells me it can create the constructor in the class.

So I tell it to go ahead and do that by clicking on the link. Now keep in mind I had already created the public properties for this class that will expose the arguments in the constructor.  So what did Visual Studio do?  It knew which arguments to assign to the private class variables automatically and wrote the constructor for me and assigned the arguments to the variables.

Sub New(ByVal userName As String, ByVal propertyName As String, ByVal operation As String, ByVal originalValue As String, ByVal newValue As String, ByVal timeStamp As Date)

   ' TODO: Complete member initialization 
   _userName = userName
   _propertyName = propertyName
   _operation = operation
   _originalValue = originalValue
   _newValue = newValue
   _timeStamp = timeStamp

End Sub

Cool!

till next time…

Technorati Tags: Visual Studio,User Stories,Audit

Back In Time: NUnit Again

So I have been tasked with implementing unit testing in some legacy code that uses Visual Studio 2005.  For various reasons this code base is not ready to be converted to the newest version of .Net.  That being said, it is a sizable chunk of code and really needs to be refactored and tested.

There are no unit tests for this codebase. So now is the time to add them.  Since we are past the Test Driven Development option we are now going to try Defect Driven Testing.  Every time a defect is found or reported, we will write a test that proves it is a defect and then green the test to fix the defect. We will also try to refactor areas around the code in which the defect was found. But before we refactor we will write tests so we are assured not to have changed what the code was doing.

Visual Studio 2005 does not have the MS Testing framework unless you have purchased the "Test" version of Visual Studio.  VS 2008 and forward included the testing framework by default.  So I downloaded Nunit.

Now I haven't used Nunit since 2008 so I wanted to make sure I had everything working.  I tried running the sample tests that were downloaded with the installer. I opened the samples solution and keyed ctrl-shft-b to build the solution. Fail.

I thought, what? This should work out of the box.  Well, it didn't.  The nunit.framework reference in the project had the little yellow warning triangle  because it couldn't find the assembly.  So I removed the reverence and added it again. Voila! It compiled.  Great, moving on.

Then I added Nunit as an external tool like I remembered I had to do to get a quick link in Visual Studio.  So I clicked Tools/External Tools menu and it brought up the External Tools form.  I clicked Add to add a new tool and added the path and the name of the tool.  Then I forgot what to put in the Arguments and Initial Directory fields so a quick Google search gave me the answer. Or so I thought. 

Several links on Google said to set Arguments to $(TargetPath) and Initial Directory to $(TargetDir).  This did not work.  So what does a guy do who can’t get a software package to work? Look at the documentation, of course!

Well right there in from of my eyes, the Nunit documentation says:

Running From Within Visual Studio

The most convenient way to do this is to set up a custom tool entry specifying the path to NUnit as the command. For a VS2003 C# project, you can use $(TargetPath) for the arguments and $(TargetDir) for the initial directory.

With Visual Studio VS2005 this becomes a bit harder, because that release changed the meaning of the 'Target' macros so they now point to the intermediate 'obj' directories rather than the final output in one of the 'bin' directories. Here are some alternatives that work in both versions:

• $(ProjectDir)$(ProjectFileName) to open the VS Project rather than the assembly. If you use this approach, be sure to rename your config file accordingly and put it in the same directory as the VS project file.

So I did changed the Argument and Initial Directory settings to be $(ProjectDir)$(ProjectFileName) and it all worked!

Interesting how things get remembered.  Someone else must have figured this out at my place of employment back in 2008.

Till next time...

Technorati Tags: Unit Testing,Visual Studio,NUnit,Tools

Strong Management in Agile Development Deflect and Prevent Distractions

I remember in High School listening to Bill Cosby when he did the bit on parenting.  How he compared parenting to being a hockey goalie, I think.  The parent needed to deflect one tantrum after another or something like that.  It has been a long time since I listened to a Bill Cosby tape.  That was funny stuff back in the 70’s and 80’s.

Little did I know then that what Cosby described would be applicable to leading and managing teams. A good leader can be like a hockey goalie with his team as the net and all the distractions as the puck. He does his best to prevent the distractions from causing in-efficiencies on his team.

What do I mean when I say distractions? This can be a very broad range of items but in the software development world it can generally include things like unnecessary meetings, office politics, feature and scope creep, pet projects that aren’t a priority to the business.  There are many more but these are a few I have observed over the last few years.

In an agile development shop teams are supposed to be communicating and interacting directly with each other and with stakeholders on a daily basis. This means someone from the business needs to actively participate in the process of developing the software and have the authority to make decisions regarding that software. In some instances the stakeholders are represented by a single person. This person should have the authority to make decisions and communicate with the team when ever they feel the need. It is management’s responsibility to give this person the tools and resources to be as efficient as possible in this communication.

Some may think this contradicts the deflection theory because “why on earth would a business person talk directly to a developer?” (Yeah – I heard that), but I disagree. The key to deflection is the unnecessary bit:  things that are not required to move the project forward.  In my view this communication is required. Not only is it not a distraction but it is, if done right, one of the single most important aspects of software development.

This is where management plays a key role in the agile world. Sure the teams should be self-directing and be made up of all that are required to push the product to the customer. But management is important here because they hold the bigger picture in hand. A good manager will work with the development team and the stakeholders to be sure there is proper direction and focus. He will prevent any distractions that may result in loss of velocity. He will give guidance when there is a conflict in the priority of stories. He will prevent the office politics from interfering with the movement of the team.  He does all these things so the team doesn’t have to; so the team can do what it does best: produce software that meets the customers prioritized requirements.

Thanks to Bill Cosby I enjoyed some summer nights with friends around the tape deck in my youth. I didn’t know, at the time, that my career would have some basis in his comedy.

Till next time…

Technorati Tags: Management,Agile Development

New Buzzword in Software Development–Craftsmanship

9PAUXZYJ7299

There is a new buzzword in the Software development industry.  This buzzword is “Craftsmanship”  There is a Manifesto. There is a conference SCNA. There is a website.  There is a new Academy. And there are many followers, one of whom I had the pleasure to be trained by back in 2006, Uncle Bob Martin, and one I have lunch with every now and then, Jared Richardson.

This is a new buzzword but it is not a new word to the industry. From everything I can gather it originated in Steve McConnell’s Book Code Complete: A Practical Handbook of Software Construction.  In this book, (which every software developer in the world should read) Steve talks about the construction metaphor as it relates to software development. This linking of craftsman in construction to craftsman in software development is not a new thing.

What is new? Well, what is new is the pervasiveness of the word as it applies to software development.  Software engineers are beginning to call themselves craftsman. The connotation of good craftsmanship is something that we all can strive for.  It is a belief that we need to take some pride in our work and always do it to the best of our ability and if we discover that we made a mistake then we own it and fix it.  This notion is spreading amongst our community at a rapid rate. 

The community also champions many extreme programming practices like pair programming and test driven development. These are practices that enhance our craftsmanship while developing solutions to problems. I am very pleased that this word is becoming a part of our nomenclature. I have not always considered my work as full of craftsmanship, but you better believe I strive to fill it to the brim now.

Till next time…

Technorati Tags: Software Craftsmanship,Agile,SCNA

Software Environments: Separation and Configuration is Key

I just left a meeting with several folks from the server group, the web services group, and my applications group.  The discussion was around environments and promotion of software through these environments. Let me tell you, there are some very different ideas out there regarding this process.

I thought I would let you know how I prefer to make this work so that there is the best opportunity for a successful installation. Now these concepts are not specific to internal software development where the customer is part of the same organization as the group developing the software. These concepts are the same for shrink wrap or cloud based software.  I have worked with all of these types of software development projects and have been successful utilizing these concepts.

The first, and arguably one of the hardest to implement, is the concept of a separation of environments. The separation of environments from step to step should encompass all pieces of a software system wherever possible. This means that each environment should have, where applicable, a web services server, an application server, a database instance (server if possible) to name a few. 

At a minimum a team should have three such environments; a development environment, a test environment, and a production environment. Each containing a distinct and atomic system that requires gates to be passed in order to achieve entry.

These gates should include automated unit tests and code analysis. The code deployed in each environment should have been proven in the previous environment. The automated code that does the actual deployment to each environment should be exactly the same in each environment so you are always executing the same thing from environment to environment and not creating unnecessary variables.  This allows you to have the experience of many deployments prior to the one crucial deployment to production, thus mitigating and alleviating most risks of deployment.

One of the single most important aspects of achieving separation of environments is Configuration Management. Configuration Management is the management of all pieces of a software product’s lifecycle from initial coding through deployment. Configuration Management as a discipline in software development is getting more and more respect these days, for which I am very happy. This is a very challenging aspect to any software development project.  A properly maintained and automated configuration management system is a must for any organization that puts any product into production ands wants to do it as efficiently as possible.

It is the details of each system where a configuration management engineer earns his money. Each will be different based on the product, but the concepts are the same.  One of my favorite books Software Configuration Management Patterns deals with some of these concepts and how source control management is an integral part of the process.

No matter what system you are working on, try to keep your environments separated and remember: automate, automate, automate.

Till next time…

Technorati Tags: Configuration Management,SCM,release planning

ASP.Net – Code Behind and the Times

In 2001 Microsoft gave us ASP.Net.  The successor to what we now call “Classic ASP”. This brought the full power of the Visual Studio IDE to web development. Allowing us to write “Code Behind” in our favorite language, either Visual Basic or C#, for WebForms development inside Visual Studio.

This was a significant improvement to Classic ASP and to the developers ability to quickly produce web applications based on Microsoft Technology.  Up till then we had to use Visual Interdev. And was that a mess or what?

While I was an engineer at FM Global back in 2001, I was on the team that adopted .Net while it was still in beta.  (I know, pretty progressive for an insurance company, huh.) We had Microsoft consultants on site what seemed to be 24/7. We were learning a completely new way to code in a completely new IDE. Visual Studio .Net was simply amazing to all of us.  We were all Visual Basic developers then and being able to code using VB in this new environment was fantastic.

A couple of years later we were building an extranet application for our clients to be able to access their insurance information on the web.  We had been programming in .Net for a while but we were still VB programmers.  We were writing procedural code in an Object Oriented world.  There were some Code Behind methods that were several hundred lines of code long and full of spaghetti.

This is when we started learning about how VB can be a fully object oriented language and about utilizing Agile development techniques to help with the quality of our code.  It all started to come together. Our designs improved because we started to design our code to be testable. Our time to build and release methods were being revamped so we could be more efficient.  We were using code generation tools. It was a time of great learning.  We made our share of mistakes but all-in-all it was good.

Why do I reflect on such times?  I was reminded about these times because I am currently working with a group that is in a very similar situation.  Folks who are mostly COBOL programmers learning ASP.Net for the first time or are early in their object oriented programming learning and none of them have any Agile exposure at all.  I am sharing my experiences with them to help them grasp some of these concepts.

While doing a code review, one finds an asp button with an OnClick event that has 300+ lines of code in it, one is reminded of these times.  I am coaching my team in the craftsmanship of Agile Software Development, Object Oriented Programming and ASP.Net. So it behooves me to try to remember where I was and remind myself that there was a time when I wrote 300+ lines of code in a single method.  Well, maybe not that much but still…

Till next time…

Technorati Tags: Visual Studio,Agile,Object Oriend Programming,Microsoft,ASP.Net

Estimation: why can’t we get it?

In software development shops across the world there is absolutely nothing more frightening to software developers than estimating a task. The fear stems from the unknown. The phrase “I don’t know what I don’t know” comes to mind.

The pressure of giving an estimate for a task in terms of amount of effort can be very heavy. Somehow telling someone how long it will take to get this task “done” has turned into a self defense mechanism. So-much-so that sometimes engineers “pad” their estimate to almost twice what they believe it will actually take.

And then, the project managers get ahold of the estimate and they pad another 50%. This brings the estimate to 3 times what the engineer actually thought the task was going to take. And you know what happens? It takes that long or longer, but rarely does it take shorter.

Why? Why do we always end up taking longer than we originally thought? In my experience there are a few reasons for this phenomena. Each of which has played out in development shops that I have been a part of.

The first is the self-fulfilling prophesy syndrome. This is when a developer fills the estimation time because he has the time to fill.  In this scenario, if you give an engineer 8 hours to do the work, he will take 8 hours to do the work. In my estimation this is the worst kind of situation a development shop can be in. Because this is a good indication that your engineers are bored and do not have a vested interest in the shipping of the product.

A second reason estimations are off the mark is because engineers don’t learn from what they have previously estimated. Even green engineers right out of college have some experience estimating. They do it every day of there live in college. How long will it take to get this homework done so I can head out with the guys and play Gears of War? When an engineer is able to take into consideration previous work/estimate relationships and contrast with the complexity of his current task, that engineer is already more accurate.

Another reason is because the task is to great to estimate accurately.  This is the one thing I see more often than anything else.  An engineer has not taken the time to break down the task into manageable chunks. I like to pose this question to my team: Which estimate is going to be more accurate? 1. How long will it take to drive from downtown Raleigh to downtown Durham given moderate traffic conditions? or 2. How long will it take to drive from downtown Raleigh to Times Square in New York City? Of course we all know the answer. Because when we estimate small chunks we are more accurate.

There are more reasons than these but these make up a great percent assuming it is the engineer giving the estimate.  If it is not then there is a bigger issue that needs to be addressed in the organization.  So when an engineer thinks a task is going to take 4 hours he should estimate 4 hours and not pad anything.  He should then take into account how long it did take and what happened during that time. He should use this knowledge the next time he needs to give an estimate. He should also learn to be breaking down his tasks into realistic estimate-able chunks. Some say if it takes longer than a day then it is more than one task. I am not going to be that stringent but I think that is a good target.

Estimating is a skill that gets better with practice.  In the Agile development world we give estimates every iteration and every day. It is the only way to get better.  Keep at it and don’t get discouraged.

Till next time…

Technorati Tags: Estimation,Agile

Math in Middle School and High School. How important is it?

Microsoft did a survey of College Students and parents about Science, Technology, Engineering, and Math (STEM). STEM, over the course of the next decade or 2, will be where most of the worldwide higher paying jobs will come from.  Are your Middle Schools and High Schools preparing your college bound child well enough for them to succeed in STEM?

According to the survey, the answer to the question is a big NO.  Most of the parents and college students surveyed believe they were not prepared enough in their respective secondary education institutions for what they needed in college.

Why do I think this is an important subject?  Because I believe it is true.  I am very fortunate to have a son in the 8th grade who is an honor student (He gets that from his mom.) My son, Brendan, is not a good student. He is a GREAT student. He has consistently scored the highest or one of the top 3 highest scores on his EOG (End of Grade) tests. North Carolina’s answer to “No child left behind”.  And he is consistently one of the best students in his grade.

Now, I am not one to brag. But I will now.  Brendan was invited to participate in Duke’s TIP program for seventh graders last year.  Through this program he was able to take the SATs with college bound 11th graders this past January.  He did extremely well. And now has all kinds of opportunities world wide that are available for him to participate in.

How did he get there? He was very fortunate to have math teachers who realized the simple truth that is stated in the results of Microsoft’s survey.  Math is important! In fact, in the Orange County School System, advanced math is emphasized and encouraged in the Middle Schools.  Brendan started with Algebra in 7th grade and is now taking Geometry.  (He is also taking English 1 so he will get High School credit for it.)

What does Brendan want to be when he grows up? An engineer!  He has already showed a preference for his mom’s alma-mater Purdue.  He also realizes that math is what is going to help him succeed.  (He also dreams of being a professional Goalie in the Premier League as well, oh well, so much for math.)

We as parents need to be a part of the equation (pun intended) as well. We need to encourage our kids at an early age to look at math as something fun and interesting. I remember driving Brendan to and from pre school singing our numbers to 1000 by tens. We had lots of fun.  So yeah, math is important, and fun too!

till next time…

Technorati Tags: Microsoft,Math,Engineering,STEM

This Will Make Someone Happy

Today I read a blog from Sean McCown that encourages developers to be professionals when it comes to interacting with a database.  In a nut shell, (Go read his blog for more) he says that coders should not write code a specific way to make the DBA happy.  They should write the code that way because it is right way to access a database.

I appreciate Sean’s sentiment and would like to take that a bit further.  This paradigm should be applied to all disciplines surrounding an application developer.  Whether it be the DBA, the QA analyst, the Build Engineer or the Automation Engineer. They all have the “right” way to access or to test or to automate. These are not because they want to make things hard for the app dev, no. It is because each discipline has specific knowledge about how their systems work the best. 

Just as a DBA can say this way to code will retrieve the data you want faster and more reliably than the other way, an Automation Engineer can and should say, coding this way will make the automation work more efficiently and have a higher quality return rate.

A coder will have a greater understanding of where efficiencies can be gained in his application if he can reach out to these disciplines and understand the “whys” instead of just making someone happy.

Till next time…

Industry Shake-Up?

Some of you know that I work in the Video Game industry.  See my last post.  I do not work for a company that makes games.  I work for a company that makes what is called a “Game Engine”.  If you are not a gamer you have no idea what i am talking about.  If you are a gamer then you are familiar with the term. The company I work for is called Emergent Game Technologies.

Yesterday, another game engine maker Epic (Makers of the Unreal Engine), decided to offer part of their engine to developers for free.  Yes, that’s what i said, for free.  Most around the office here, upon hearing the news, were a little pissed off.  But then most of us started to really look at the announcement to try to understand what it meant to Epic (the makers of Unreal) and to us as a game engine company.
What does this mean to Epic?

1. Sales leads
2. Sales leads
3. Sales leads

When you download the engine from Epic, you supply all the standard info.  Epic then follows your progress. 

Then there is the gotcha.

• No Support - To quote Epic directly "Epic Games, Inc. will not be providing direct support for this product. "
• If you develop an internal application, you pay Epic $2500 per seat, per year.  To quote Epic directly "If you are using UDK internally within your business and the application created using UDK is not distributed to a third party (i.e., someone who is not your employee or subcontractor), you are required to pay Epic an annual license fee of $2,500 (US) per installed UDK developer seat per year."   Did I say free above?
• If you develop a game and that game is sold with revenues greater than $5000, you pay Epic $99 plus 25% of your revenue.  To quote Epic directly "If you are creating a game or commercial application using UDK for sale or distribution to an end-user or client, or if you are providing services in connection with a game or application, the per-seat option does not apply. Instead the license terms for this arrangement are US $99 (Ninety Nine US Dollars) up-front, and a 0% royalty on you or your company's first   $5,000 (US) in UDK related revenue, and a 25% royalty on UDK related revenue above $5,000 (US).  UDK related revenue includes, but is not limited to, monies earned from: sales, services, training, advertisements, sponsorships, endorsements, memberships, subscription fees, rentals and pay-to-play." Did I say free above?
• Only available for PC development.  If you want consoles, you pay Epic their normal price for the engine.  Did I say free above?

So, to my untrained eye, what this means is Epic will get money from you some way or another. This is great for Epic. A smart move. You could basically say that this is just a glorified, extended evaluation of the product. A single AAA license that comes from this move could mean Epic brings in a half million dollars. And that is conservative.

This is not necessarily great for game developers. It limits their choice because they will immediately go for FREE. I equate this to Microsoft offering Internet Explorer for free back in the 90s. I started using it, because it was free. But, the industry paid for it in the long run. Now we have less choice. Sure there is Firefox and Chrome. but those are relatively recent. It took a long time for competition to get were they needed to be to break Microsoft’s hold on the market. They are still trying.

What does this mean for Emergent Game Technologies?  We differentiate ourselves in a couple of ways.

1. Our support to customers and evaluators is second to none.  Does Not Change!
2. Our product, Gamebryo LightSpeed, addresses the rapid proto-typing, rapid iteration areas of game development like no other product. Does Not Change!
3. Sales – This is the change – We now have to address the gap.  Those startups looking to evaluate an engine that will grab the first one they can get their hands on.  I can assure you, our Sales and Marketing Team is already implementing a strategy that addresses this space.

Will Emergent become the Netscape of game engines and fade away into (made with Gamebryo) Oblivion? I wouldn’t count on it.  Will Epic continue to dominate the market and grow market share?  In the short term, yes.  But who knows what tomorrow will bring.

Till next time…