Enterprise Etc Adventures and Insights of a .Net Developer

It's been a really busy last several weeks.  We've been working to get the application I'm currently working on into production and after considerable deliberation, I've decided to leave the ranks of the contractors and accepted the offer to become a full time employee of a local telco.  I'll be serving as IT manager and will be managing systems administration as well as software development.  Wish me luck as I endeavour to exceed expectations.

I'm currently working on a project that began in March of last year.  A friend of mine is managing the project and after he brought me on, we decided to try and make things as pleasant and as fun as possible for the project team.  I purchased a couple of novelties that we awarded developers when they broke the build or were deemed the most productive.  We blazed through requirements and watched features get implemented swiftly.  I was having a ball and it seemed the whole team was enjoying working on the project. 

Around mid summer, though, something happened.  Several, previously unknown, requirements were uncovered and while they were added to the project, the timeline was not adjusted.  I marveled that in the space of about a week both motivation and productivity dropped noticeably.  I felt my own attitude about the project begin to change and in asking myself why I identified a few things that motivated me and a few that did not.

What Motivates Me

• An opportunity to learn new technologies is always a motivator.  Looking back, I've always been willing to put forth the extra effort and spend the extra time to stay as productive as possible while learning about new tools, languages or language features.
• Trust.  When a task has been delegated to me and trust has been placed in me to get the task done, I've always risen tot he challenge.  In fact, any gesture that communicates, "I believe in you and your abilities." is bound to motivate me.
• Organization.  When a project is well managed and organized so that I can concentrate on what I do best (design and build software), I find I have more energy and apply myself better to the tasks at hand.  

What Robs Me Of Motivation 

• Repetitive tasks.  Copy / paste, boiler plate code...yuck.  Can't we automate this task and move on to something else??
• Micro-managing.  I think of myself as a professional and I don't think its too much to ask to be treated that way.  Ask me if I can perform a task.  If I tell you I can perform it, let go of the task and give it to me.  I'll give it back when it's completed.  I promise.
• Surprises.  Whether it's formal or not, there is always a plan.  When I start a project, I may not know precisely what the finished product will look like and I may no be able to tell you precisely when it'll be finished but you can bet I have a plan.  I need to know what constitutes a finished product and have some idea of how long the task will take.  When the environment in which I'm working or the projects requirements are in a constant state of flux, it drains me of energy and motivation.  Will the section of code I'm working on, right now, just be thrown away?

I'm sure you have your own similar experiences.  What has motivated you, in the past?

I've been working on some infrastructure for my contracting business.  There are a lot of things that need to be tracked when you run your own business and for me it seemed that whenever I remembered something needed to be recorded I wasn't near a computer.  However, I always have my mobile phone (Samsung Blackjack) near by and it made sense to me to write an application that allowed me to log things like time, mileage and the like from my phone.

Architecture
I could have gone the route of creating a web site for this purpose, but instead I decided to create a SmartPhone application that called web services on my server, at home.  This way, if I ever decide to write a Windows Form or Web application front end, I can use the same web services and not have to recreate the logic they provide.  The web service methods give me all the CRUD functionality I need to manipulate the data I'm storing, so all the UI code on the phone needed to do was collect data and call the web service for storage.

Writing the mobile application was very straight forward.  I set a web reference to the web services I'd written and coded against the generated proxy.  Getting used to the mobile controls and the bits of functionality not provided in the compact framework were the biggest challenges, but nothing major at all.

Lessons Learned
Getting an internet connection in the emulator
After I had written a bit of code, I was eager to see it run.  I clicked the Start Debugging button on the Visual Studio toolbar and after prompting me for a target to deploy to (choose the emulator), an instance of the emulator was created and my code was deployed to it.  When I tried exercising some code that made a web service call, a transport error was raised.  I then tried to open pocket IE on the emulator and browse to an internet address, but got a message saying that I needed to configure my network settings on the phone.  After some searching, I figured out how to set it all up.  First, make sure you have ActiveSync installed and running.  Then, right-click its tray icon and choose "Connection Settings" from the context menu.  Make sure the check box for "Allow connections to one of the following:" is checked and select "DMA" in the combo box. 

In Visual Studio, go to the Tools menu and select "Device Emulator Manager...".  When the dialog opens, right-click the entry for "USA Windows Mobile 5.0 Smartphone R2 QVGA Emulator" and select "Connect".  This will open an instance of the emulator.  Next, right-click the same entry again and select "Cradle".  At this point, ActiveSync should detect the emulator and treat it as it would a physical phone plugged into the USB port of the PC.  Once you go through the connection wizard, you should have access to your PC's internet connection from the emulator through ActiveSync.

Deploying to the SmartPhone
Once my mobile application was unit tested, I was ready to deploy it to my phone.  I connected the phone to the PC, right-clicked my mobile project in Visual Studio and selected "Deploy".  The phone popped up up several dialogs asking me to approve the installation of several files on my phone.  I approved all of these, but the deployment still failed.  The reason stated indicated that there were some certs needed on my phone to deploy for development.  To get past this error, copy the file ...\Program Files\Microsoft Visual Studio 9.0\SmartDevices\SDK\SDKTools\VSDCerts.cab to your phone.  Then, on the phone, open the cab file to install the required certificates.  The deployment should succeed after this is done.  Of course, if you're developing an application for distribution, you'll want to properly sign your application instead of taking this short cut.

 

In the developer space, it's astounding how fast new technologies are arriving.  In order to stay current, a developer has to become digest the new tools and approaches, ty to get some hands-on with them and then possibly retain that new knowledge without being in a position to use it day-to-day.  Contractors or consultants, especially, need to be able to keep their tool belts well stocked with the a wide assortment of tools, technologies and methodologies both because of not being able to predict which of them the next client may utilize and also because since the right tool always makes the job easier it makes sense to have as many as possible.

With all this in mind, when it comes time to hold a code review, upon what criteria will the code be judged?  We all have our favorite approaches to designing software...our favorite code constructs, favorite tools, naming conventions.  How does one prevent a code review from degenerating into a argument about which is correct?  In my view, there is only one way. 

Each team needs to spend the time, up front, to determine what standards the group will use.  How are exceptions to be handled?  Where is configuration information to be stored?  What, if any, frameworks or external components are to be used?  What unit tests and comments are to be created, minimally?  By doing this, the code review becomes an opportunity to measure the code being reviewed against a known and agreed upon standard.  This makes the review much more beneficial to the developer responsible for the code and offers a chance for the group to identify problems or omissions in their group standards and correct them.

I'll go ahead and say this to get it out of the way.  I've never worked on a project that used a purely agile methodology.  I've worked for clients that chose bits and pieces of things usually associated with agile such as continuous builds and the writing of unit tests, but I've never been submerged into a purely agile experience.  So, my comments are coming not from experience with agile methodologies, but rather experience without them.

I've been curious for the past few years about the benefits that an agile approach brings.  I've read numerous books on things like RUP and SCRUM.  As I've gathered knowledge about the subject, I've had the chance to balance the experiences I've had in the projects I've been involved with against the philosophies and practices I was reading and thinking about.  I've boiled all these meandering thoughts down to a list of perennial problems I see in projects and how I think an agile approach could lesson or eliminate them.  Of all the various flavors of agile methods that exist, SCRUM seems to be the one I identify with the most, so I'll be speaking in its terms, below.  If you aren't familiar with SCRUM, you might want to read more about it, here.

• Scope Creep / Late Breaking Requirements - With a SCRUM project life-cycle, the software design is refined before each sprint.  Further, during the course of the sprint, the goal is to write the software to meet the CURRENT requirements only.  Let's face it.  Any developer who has any experience, at all, can tell you that there will always be more features requested after the project has started and that users will always change there minds about things.  If we know this will always be the case, why do we design a whole system up front and pretend it's never going to change?  In fact, we try to insure that it doesn't change by slapping a change request and approval process on the users who change their minds.  To me, the ultimate goal is to put the most useful software possible in the user's hands.  Punishing users for suggesting improvements to the software doesn't seem conducive to that.  With a methodology like SCRUM, these changes are part of the process and thus welcomed. 
•   End Product Not Meeting the User's Needs - I think a majority of the problems that occur in software projects boils down to a lack of communication.  Communication may break down because no attempt is made to convey things like project status and the way the application will work - or it may just be that the business side of the house and the IT department speak is entirely different terms.  If the project is to be a success, the users and the developers have to be on the same page.  The only way that can happen is for the two groups to talk...often and in the same terms.  There are users who never know exactly what they want until they don't get it.  In SCRUM, after each sprint is finished, the solution is presented to the users for approval.  Users can see and maybe touch and use the software in its current state.  This seems to me to be the best way to squeeze those questions and concerns out of a user that they never seem to be able to think of when they're requesting the software. 
• Developer Thrashing - In SCRUM, there is a daily meeting to determine where each developer is with there tasks and what can be done to expedite anything holding them back.
• Pushback From the Business on Length/Cost of Projects - Before each sprint, a decision is made as to which tasks will be completed during that span of time and which developer will be responsible for each.  This decision is a COOPERATIVE effort between IT and the business.  Each task has an estimated amount of time required for completion and a priority assigned by the business.  Accuracy in estimating the effort required for a task and how much effort can be expended by the development team during a single sprint can be tuned over time and this type of metric is very easy to gather from the process.  Since the the business is involved in the scheduling of tasks and would have access to the metrics, a better understanding of what takes time and why can be had.

Though my experience with agile methodologies is light, I can tell you that the apparent benefits of applying them has motivated me to push for there use in my current project.  I'll check back in with the results.

I have several bits of code that I take from gig to gig and reuse.  I wrote a general data access layer a few years ago and have used it numerous times.  It's saved me untold hours of time.  Over time, we craft these indispensable little gems that we can plug into our applications over and over again.  I'm definitely a fan of getting to the finish line as quickly as possible and keeping an organized collection of reusable code snippets helps to accomplish that.  I, personally, prefer to keep these pieces of code in a code repository on a server at home.  I have my repository set up so that I can access it from anywhere across the internet and when an opportunity to use one of these snippets arises, I pull it down and put it to the task.  As far as organization, I find that arranging the code by Layer and then by purpose is sufficient. 

I recently read a book on building wealth in which the author indicated that the amount of money you're making is not the important thing when building wealth.  The acquisition of assets that generate income...and keep on giving...was the key.  No matter how many lines of code you can write in a day, code assets will save you time and make you more productive.