Once a project goes live, it is often the developer who supports that system in production. The project manager has moved on to the next project, but the developer must support the application in the production environment. This involves follow-up and responding to issues as they arise. I confess that I have become comfortable with the implementation focus. I am finding that I have to remember to focus on production support, now that I am also contributing to the project in the developer role.

My role, as I understood it, on the project that “got me” was as the project manager only. Because of this, I was reading the requirements through my project manager eyes. My developers were reading the requirements through their platform-specific eyes.  The result? We completely overlooked an area of development that was sprinkled throughout the requirements.

It happened to be a platform on which I am doing development on for other projects, so I can easily see how it was missed. The assumption was that I would take care of that piece, only I didn’t make the same assumption. The problem showed up in a reported defect, so now I am scrambling to catch up. I must be certain to analyze the requirements more carefully so that as the project manager, I make sure that all the developer skills we need are on the team, whether the developer is me or someone else.

You might think that this problem was obvious and could have been avoided.  I can tell you that it wasn’t obvious to all who were involved because it was missed in two sprint planning sessions. Yes, it wasn’t obvious, but I should have caught it.

Here is my story.  I went into management for a better salary.  Back when I did that, I had reached the top of the career path for developers – Systems Analyst. Several years into my time as an IT Manager, I was tapped to lead the Project Office.  I oficially became a project manager and earned my Project Manager Professional (PMP) certification.

The more I worked with software development teams, the more I missed doing software development. As a PM, I also saw problems with software development that I figured would be hard to improve unless I got involved in the work.  A hands-on approach would show me what was going on and build credibility for potential solutions.

My problem?  Besides the tinkering I do in my spare time, most of my programming skills are rusty, out-dated, and underdeveloped. That being said, I have always been able to learn new things. With budgets tight, it is up to me to get started and prove my value. This is where the web really comes handy.  There are so many good, free resources available for learning!

Here are a few that I am using:

• VB Programming for Non-Programmers! – This course will get your feet wet.  It comes in four weekly installments and is easy to follow.
• SQLCourse.com has an Introductory SQL Tutorial.  SQL is a manditory skill for querying relational databases.
• Learning the Java Language – A free course from Sun covering the fundamentals of the Java language.
• JavaBat – Innovative web page with Java practice problems.

Here are a few articles worth reading:

• Five Ways to Become a Better Software Developer – This one surprised me, as most of the tips involve networking and getting feedback from other developers.
• So how do you become a great software developer? – Another surprise – read! At the core is being able to understand the problem you are solving.
• Platform Engineers or Rock Star Engineers – It’s all about passion, skill, and understanding. The Rock Star Engineer can solve problems using whatever technology you put in front of him.

Finally, a couple book lists:

• Do you want to become a great developer? – This list covers a lot of different topics, but none of the books are language-specific.
• How to become a Great Software Engineer – Once again, most of this is not language-specific!

Here is a quote from the “Rock Star” article referenced above that sums it up nicely.

I’ve lost track of how many times this simple fact has been proven to me. The qualities of a great engineer carry over to any platform, and a great engineer will pick up a new platform quickly — mostly because they love learning new things. If you’re starting out in software development, concentrate on being a great engineer. That’s far more valuable than an engineer that knows a platform.

I have seen this too. If you look at the articles and book lists I’ve noted above, you will see that very little is said about specific languages.  The languages are just the tools.  They are important and you need to know them.  However, it’s not the knowledge of languages that make a developer valuable.  It’s the higher skills – learning, networking, understanding, and problem solving.

The BA’s on our team came to me later and spoke to me why these small tasks were important.  (They weren’t sure they could speak to the impact  during the scrum.)  The accuracy of a key calculation, which is being tested right now in another system, was at stake. I requested that the developer put aside the larger task and complete the small tasks today.

As scrum master, I was acting to remove an obsticle that a different team was encountering. I also wonder what could have happened differently so that I wouldn’t have had to intervene. Could it be that with just a little extra push, the developer could have completed this task earlier so it wouldn’t have become an issue?  Could it be that the importance of this task been discovered earlier in our sprint?

What do you think?

JavaBat is a free site created by by Nick Parlante who is computer science lecturer at Stanford. It contains numerous coding problems and gives immediate feedback if your code solves the problem correctly. (The site can also be a good tutorial on unit test case development. Just study how the test cases are structured.) Helpful links to tutorial pages, as well as sample code, help you learn.

The site focuses on improving your method coding skills. Each area has a large number of problems to solve, ensuring that you can get plenty of practice. It also has the facility to enable a teacher to monitor the progress of his or her students.

I would bet that both new and experienced developers will find something on JavaBat to help strengthen their coding skills. It could also be used as a tool in evaluating potential developers you want to add to your team. Finally, I also like the the minimalistic design of JavaBat.

He lists eight points that help programmers and makes the following observations:

• It’s striking how often programmers manage to hit all eight points by accident.
• Even more striking are the number of officially sanctioned projects that manage to do all eight things wrong.

It looks like there is plenty of room for managers (and programmers) to improve!

Industry data shows that outsourcing saves 20%.
Outsource the project above and it costs you $1.6 million.

Introduce Scrum locally and you can realize a 240% improvement.
Local Scrum for the above project only costs $0.83 million.

Source - Jeff Sutherland - 2006

• Pretty straight-forward concepts: Scrum Basics
• Another quick overview of Scrum: SCRUM in Under 10 Minutes
• Google Tech Talk with Jeff Sutherland: Scrum Tuning: Lessons learned from Scrum implementation… (This runs about an hour.)
• Goofy: Agile Development with Scrum: What they don’t tell you.
• Kinda long: Agile vs. Waterfall: A Tale of Two Teams

• Part 1: Making Fans
• Part 2: Know Your Core Competencies
• Part 3: Enjoy the Panorama
• Part 4: Know What You’re Building
• Part 5: Don’t Use a Dull Knife
• Part 6: Become a Manager
• Part 7: The Jigsaw Puzzle
• Part 8: Know Your Archetype
• Part 9: How to Criticize a Software Developer Without Getting Punched
• Part 10: What Do Your Colleagues Think of You?
• Part 11: Get a Massage (and Get Your Boss to Pay For It)

If you are a software developer, I think it is worthwhile to read one part each day and reflect on it. It just might help you become a better one!