I've spent the majority of the last 4 or so years involved with or directly managing an SI team, so Keith's post is interesting in that it provides another perspective on a topic that I haven't been able to find much material on. My own practices with SI teams have been learned mostly through trial-and-error, research, and process design of my own.

Two points in particular strike me as most critical:

SI teams require their own backlog and product owner (PO). Having more than one backlog and one PO is a recipe for disaster. The team should have every benefit that other agile teams have in an understandable backlog and single vision.

This couldn't be more important. The purpose of an SI team is to provide features and support for all product teams in an organization, which means it needs to maintain commonality and robustness. The only way to accomplish this is if one voice (i.e. the PO) speaks for the SI team and one set of priorities exist in determining the work required to achieve the SI team vision.

SI teams should factor support into their velocity whether it is identified for tasks or not. Setting aside a certain percentage of your bandwidth for unexpected maintenance is critical.

I've fallen into this trap myself of not scheduling enough time for product support, which leads to slipping engine features or fixes to the right while product needs take priority (and they almost always take priority). This has the negative long-term effect of the engine gaining some design bias over time toward the products that require more support. It's not an ideal situation.

Managing an SI team isn't easy, so if you're interested in or involved with this sort of thing, take a peek at Keith's article for a few good pointers.

I go there to get away from the hectic for a few days, sometimes even unplugging from the world completely by disconnecting from Internet, TV, and phone. It gives me a chance to unwind, think, and ultimately reflect on where I am and where I want to go.

Anyway, at one point during the last few days I was thinking about the whole topic of "What makes a better software engineer?" and remembered an old article series by Chris Hargrove that we have on GameDev.net called Code on the Cob (CoTC).

CoTC was originally written by Hargrove for a site called loonygames, run by loonyboi, who has since moved on to bigger and better things. When loonygames shutdown, I contacted Chris to see if he would be willing to let us host the series, especially since he was pretty active in the GameDev.net community at the time.

CoTC is one of my favorite series of articles, not because there was any particular insight or because I necessarily learned a lot, but because Hargrove outlined best practices and principles for software development in an easy-to-understand way. Some of his ideas still resonate with me today.

In fact, there's one article in particular in CoTC that I've always remembered and it's the one that I thought of while away this past weekend: CoTC 11: The Next Stage, in which Hargrove outlines his thoughts on the development stages of a programmer. While it's hardly a science, I think he did a pretty good job of outlining the different growth stages a software engineer might go through.

At this point you may be wondering why I thought of this article when thinking about the topic of "What makes a better software engineer?" (Or better yet, you may be wondering why I was thinking about any of this while in the Florida Keys, but that's another topic.)

Well, while discipline is an important attribute to becoming a better software engineer (or as mentioned before, a better anything), another equally important attribute is a desire to reinvent yourself.

Reinventing yourself means to have an insatiable appetite for knowledge and recognizing how to apply that knowledge. It is our ability to change our habits and world views in order to become the person we are trying to be. Continuous improvement is another popular phrase that means the same thing. Essentially, "good enough never is."

I thought of Hargrove's article because his stages of programming are essentially about reinventing ourselves. As we progress through the stages we have to change our habits and perspectives on software development. If we fail to change, or reinvent ourselves, then we fail to progress and become better software engineers.

I know Stage 1 programmers with years of experience. I also know Stage 6 and 7 programmers (whatever 7 is, they are there) with years of experience. Besides their technical skill, the only real difference between the two is that the Stage 6+ programmers were willing to adapt, change, or reinvent themselves as they progressed in their careers. The Stage 1 programmers just went along with the daily grind.

This concept of the "better software engineer" is a very gray area, so nothing should be viewed as mutually exclusive. For instance, a person with good discipline may find it easier to reinvent herself than a person with little self-control, but then maybe not if the person uses discipline in such a way that it prevents themselves from changing.

At the same time, there are certain attributes that successful people have, and if we want to be successful, then it is in our best interest to learn how they do it, regardless of the field or discipline we are in.

This is a question I've asked myself often over the years, primarily because I'm constantly asked to teach others how I "do things". The problem is that I don't know how I do things – I just do it, like Nike. No really, I once said that during a radio interview.

But regardless, I've still thought about the question. As a result I'll probably post more about this because I've come to realize a number of factors contribute to the "betterness" of a software engineer (or anything for that matter), but one aspect I've thought about more seriously is discipline. Better software engineers, better artists, better management, better athletes, better anything all have one thing in common: they have discipline.

Do a blog search for "discipline and business" and check out the types of articles using the word. They all revolve around a central theme of success. It's not a huge secret, but millions appear to miss the fact that discipline does several things for you:

1. It keeps you focused. If you can't focus, then you're more likely to be distracted, which means you'll get less done.
2. It helps you "nail the details" while also seeing the big picture. This is critical in leadership, but also in engineering. The better engineers are very detail-oriented, but not to the point where it's crippling as they also recognize the big picture. The details they nail are things like processes, configuration management, quality, and good algorithm design.
3. It says, "I am in control" and provides leadership. Human nature trends away from chaos and toward organization. If you are disciplined, then you are perceived as being in control and organized, and people are more likely to drift your direction. You have your sh%t together, so to speak, and people want to have their sh%t together, too.

Maintaining discipline isn't easy. It requires constant improvement. Although, one of the best things I learned while playing baseball was the concept of WIN: What's Important Now.

The concept is simple: If you find yourself adrift or losing focus, then ask yourself, "What's Important Now?" If you answer the question honestly, then you'll know what you need to do, and you'll stay focused on achieving your goals. That's the first step to discipline.

While that seems like a lifetime ago in the software world, the concepts of the spiral development process are rooted in today’s most popular software process methodologies, including eXtreme Programming (XP), Agile, and Scrum.

You may be saying, "But spiral was 20 years ago! XP, Agile, Scrum.. they all take different approaches to development!"

Yes, they do have differences on the surface, but deep down each of these methodologies has an underlying similarity – they all use a form of spiral at every level of development, from the product schedule to actual code implementation.

Refactoring? It’s a spiral approach to software design and code improvement.

Two week builds? A tight spiral approach to managing workflow.

Use cases, stories? Enable a spiral feedback loop for better communication between stakeholder and developer.

That’s just the beginning.

Consider this: the spiral model Boehm created closely resembles the Deming Cycle of "Plan-Do-Check-Act". PDCA is an iterative four-step problem-solving process made popular by Dr. W. Edwards Deming. Dr. Deming was a statistician who helped the United States during and Japan after World War II improve production and quality control. Deming later changed PDCA to PDSA, meaning "Plan-Do-Study-Act", but the idea is the same.

An interesting fact of PDCA is that Deming based it on the Scientific Method, developed by Francis Bacon in 1620 with origins dating back to Ancient Greece. If you remember from high school science class, the scientific method is "Hypothesis-Experiment-Evaluation", each of which relate to the steps of PDCA.

The basic premise of PDCA (or PDSA) and the scientific method is very familiar to anyone studying modern software process: iteration, iteration, iteration. From Wikipedia:

"A fundamental principle of the scientific method and PDSA, is iteration – once an hypothesis is confirmed (or negated), executing the cycle again will extend the knowledge further. Repeating the PDSA cycle can bring us closer to the goal, usually a perfect operation and output."

And as if that wasn’t enough, the quality beast Six Sigma borrows from the PDSA cycle and defines it as DMAIC, or "Define, Measure, Analyze, Improve, Control".

Does this mean XP is a relative of Six Sigma? Perhaps, but I won’t go there.

More importantly, software processes will come and go in the software industry. They may have funny names and their own terminology for the word "requirements", but it’s a pretty good bet that no matter what comes along it will probably be based on the best creative engineering practices that Boehm, Deming, Bacon, and others have documented over the course of human history.

The entry, "Process and the microISV", highlights four practices that help with small developer success:

1. Hold weekly business and technical reviews. This helps you from veering too far off course from both a business and technical perspective. As I mentioned the other day, it’s important to stay the course in any development project, but critical to remain focused when you’re a small developer with limited resources.
2. Define clear end-points. This is basic goal setting. Define your vision and identify the steps necessary to achieve it.
3. Create a work schedule (and stick to it). This pertains more to those working at night in addition to the regular day job, but it’s critically important for two reasons:
   1. A work schedule can actually help make you more efficient. If you know you have a limited amount of time, you’re probably less likely to slack off.
   2. A schedule can also help life outside of work, as it allows you to ensure that you have free time for things like friends, family, and personal time. Work-life balance is important.
4. Keep a "Not Now" list. Again, focus on what’s important now and what can wait.

These are good common sense ideas, and since I found the list I’ve been trying them myself with success. If you are struggling with staying focused and getting your projects done, then you may want to give them a try, too. 

Note: A "microISV" is a term coined by Bob Walsh, owner of 47 Hats, and it literally translates as "micro independent software vendor". Basically a microISV is a small software developer of no more than a few people that builds applications not for the multi-million or billion dollars, but enough to live off and be their own boss.

Not to be rude or impertinent, or seemingly ignorant of how development works In Real Life, but don’t you have documentation of your interfaces to avoid this sort of thing?

It’s a good question.

It would be nice, but no, we probably don’t have the interface documentation being asked about. We have documentation, but in this case the code in question is considered a prototype brought into an application for refactoring.

Generally speaking, on our team prototypes aren’t documented much, unless they are fairly large or complex subsystems in which the engineer may write up a paper or presentation to describe the design. In this instance the prototype was a small subsystem, so we didn’t have a lot of documentation on hand but we did have some, although the engineer still could have used a little forethought on the task.

To explain more, most documentation we have involves high-level and conceptual documentation to describe the overall system. Class level documentation is written as Doxygen comments directly in the code, but that includes descriptions and class interfaces. We’re working on a fairly fluid project in that prototyping and feature iteration is a regular occurrence.

Also, our development practice does not focus on well-defined interfaces up front. We do, however, focus on concrete design principles. Some would say we risk bloated interfaces, which is possible, but we have yet to deal with such an issue because our design principles prevent it from happening. I’m a strong believer in design principles over design documentation.

Plus, there’s the teamwork aspect. We are very collaborative, have daily 15 minute meetings, and communicate throughout the day. We’re a small team so this works for us (6 software and some artists).  It wouldn’t work for a large team, which would probably need that interface documentation more than we do.