How does a good developer keep from creating code with a high bus hit factor?

Answer 1

Source Control with commented change logs is probably a key component.

Answer 2

Regular peer code reviews help. This means that at least one other person has to have looked over each line of code and should have requested it to be altered for clarity where required.

I constantly strive for code clarity over brevity which should help future developers. However, there are occasions where you can't help but write code that is slightly obtuse. In this case I gather the team together for 30 minutes to run through a high level idea of how the code works, if not a full explanation.

A suite of unit tests also help other developers to have confidence in altering code as they will then know when they make a change that breaks part of the system. If well authored they can also explain how parts of the system are intended to work through naming rather than purely through code.

Answer 3

As a good developer you should not care about your bus hit factor. The important thing is that you decide when to run in front of the bus, and not your employer.

Answer 4

Debugging is hard. Thus, if you are coding as cleverly as possible, you're going to be too stupid to debug the code.

• Simple code improves maintainability
• Code reviews control for simplicity
• Project managers carry responsibility

Answer 5

There should always be duplication of knowledge in an organization.

Just like you would always back-up your hard drive (right???), you don't want one person to be the sole possessor of important information. One way to mitigate this is to have programmers work together.

What you mention as the "bus" problem is, more practically, the "what if Joe moves away / decides to quit" factor. Generally, employment is at-will, and anyone can leave at any time.

A resilient organization cannot rely on a single developer possessing all important knowledge.

Answer 6

By following Agile development processes which promote "ownership" of the entire codebase by the entire team.

Answer 7

Source Control and well thought out and commented code are key.

The people responsible for ensuring this doesn't happen really is everyone involved with the code. The Dev managers and the PMs are the people who should keep a close eye on it, but executive management has to put policies in place to support them and have resources available to ensure that multiple people having overlapping areas of knowledge is possible.

Answer 8

I'd say code that has good unit tests. For the replacement developer joining the project knowing that their changes are not breaking other parts of the system is important.

Answer 9

While I was working as a student programmer at my University during my undergrad my Bus Hit Factor had to be closely managed. I was working on major projects yet my employment there was only until the day I graduated. At this point other programmers in the department would have to pick up my project and manage it from there. I managed this with buckets of documentation.

Since the day I started at that job, I did my best to keep my specifications, code and other documentation as up to date and clean as possible so any competent co-worker could pick up a solid understanding of my work in a matter of days (with or without my help). Each project of mine would have a corresponding Confluence Wiki where I would keep all documentation, diagrams, specifications and little 'tidbits' for other developers to know.

It also helps if you have a good clean coding style. If your code makes sense and is easy on the eyes, other programmers should be able to pick it up after your unfortunate bus accident.

Answer 10

The most difficult part of maintenance IMO isn't knowing what the software does or how it does it: it's knowing what the software is supposed to do.

If I know ...

• What the software is supposed to (i.e. the functional specification ... I don't necessarily need the design specification)

• How to build, how to run, and (following from the functional specification) how to test the existing software

... then that's the most important thing. Other documentation (e.g. "design": which describes how the functional specification is implemented by the software) might be nice to have too, but it is comparatively optional and less important than the above.

Most developers will answer your question by saying "comments in the code, well-named identifiers, source control, etc." ... but I think that more important is "as a developer, if you're writing software which has no written functional specification, then write a bit of functional specification to go along with your software." An FS will be useful even before someone tries to maintain the software: it will be useful to QA who want to know how to test the software.

And, who is responsible for insuring that the developers, brought in to maintain a bit of code, are able to understand it?

Typically that's the new developer's team leader (i.e. the senior programmer who already knows the existing code); but failing that (if there is no such team leader) it might be a manager (product or project manager, or "release engineer") if that manager knows where to find the software's functional specifications and build instructions.

Answer 11

Pair programming mitigates this risk to a fairly high degree. If you can't do that (many of us don't have the luxury to pair up on every project), you can always schedule regular peer reviews and document your code as you go, as opposed to documenting at the end.

Answer 12

In order of importance (obviously this is my own opinion):

• Clearly named objects, variables, and function names
• Clear comments
• Source Control
• Code Reviews
• Reasonable bug-tracking software, with actual notes about what happened.
• Documentation where necessary (but only where necessary; too much just makes it hard to find what you need)

And the person responsible for that? You, of course.

Answer 13

Simply by having more than one good developer...

Answer 14

Losing a key team member happens often, whether temporarily or permanently. Whether someone is taking a long lunch, or the flu is going around the office, or a programmer wants change roles within the same company, or a goes through a painful divorce, or quits to sail around the world, or is tragically harmed, the prospect of a sudden and unexpected change in the team is inevitable.

One of the attributes of a good developer is that they strive to reduce their team's "bus factor" by making them selves less essential. That's hard to do when you're feeling insecure about your job. A good manager creates the security people need to relax about this sort of thing.

Practices, roughly in priority order:

1. Well-factored code means your intent is written in the code, and eliminates secrets.

2. Thorough Unit Tests serve as both a kind of documentation and as a safety net when a secret-holder is not available. (That is, they are verifiable documentation.)

3. Pair programming, especially Promiscuous Pairing, will spread knowledge over the development team and exposes secrets.

4. Shipping often means that even if something happens, your customers already have a recent, working product, and you have a known quantity to roll back to if things go haywire.

5. Documentation, both in comments and elsewhere, stores ideas and intent that can't be expressed in code. However, documentation is expensive to create, expensive to consume, expensive to maintain, and often ignored, so the other items are preferred.

Answer 15

By not coding in isolation. Talk with others on your team about the code you're writing. Have code reviews. Implement common strategies for solving problems. If you are on the same page as everyone else on the team, your bus hit factor will be low.

However, if you are a lone developer, several of the other posts here already cover the ideas of coding standards, documentation, etc.

Answer 16

Well written code is probably the optimal solution. By well written, I mean that the statements are concise, the variable and method names meaningful, and the system well designed. And very importantly - doing this should not impair the developer's current processes.

Voluminous documentation will be a hindrance - both to the current coder and the future coder.

Formalized processes (like unit testing) are a hindrance to current development speed (unless of course the in house coder is a proponent of the process).

An army marches at the pace of its slowest marcher. Pairing another programmer to someone who is very productive will slow them down. Very rarely does a shop have more than 1 super productive coder.

Answer 17

The project should be easy to check out and setup. In our company, all projects are CVS and Eclipse and Maven, so upon Checkout, you do "maven eclipse" and you're all set.

From there on, you need a good developers manual (not a 500 page document, just the essentials to get you going). The dev manual points to different documents, where developers can find info on the design and other stuff.

A bug tracking system is a must, and good descriptions in the bugs are a must.

Try to comment your code, and keep javadoc up to date.

Good unit tests also help. Try to keep unit tests a simple suite, where you can just run them all without having to configure all kinds of stuff.

Hope this helps.

Answer 18

Everybody in the company is either part of the solution or part of the problem.

If somebody gets hit by a bus, and you aren't screwed, it means that this somebody was part of a problem. You don't want to extend the problem area in your company just to keep the bus hit factor from growing.

And vice versa - if somebody useful gets hit by a bus, you're always screwed, no matter what. The more the late person was contributing to the company, the more you're screwed.

The bus hit factor is not something special existing only in software development but rather a general business risk.

So, the answer is: don't expect a pure business risk can be solved magically with some technology, tools or methodology. Think wanilla business 101. Estimate the risk, estimate the cost of mitigating it, compare the figures, act accordingly.

Answer 19

I am having this problem right now. Basically the deadline is insane and there is no ramp up time left for other developers.

I think the solution is to have more than 1 developer design a system from inception. ALWAYS. Three developers is better (I know it's Google's favorite team size). That way more than one person understands that system from its core and up, intimately, knowing how it works and WHY it was designed that way.

You can say "but what about the resources in a small company?" Too bad, if you have two developers and three simultaneous projects, both developers should shuttle between all three of them, exchanging ideas and sharing the workload, even though it is very costly and inefficient to have that sort of shuttling. But long-term, the entire team will be one expert entity on all parts of the code.

Otherwise, at some point someone completely unfamiliar with the code will come on-board and vandalize it, with the best intentions, of course. And here you go, a perfectly good system, maybe even a company's crown jewel, going down the hill. Poof.

Answer 20

The c2 wiki used to have an article with a name along the lines of "Don't Trust a Developer in a Room for a Month". The reference was to project plans with line items like "Implement System, Fred, six weeks", where project management consists of conversations like "How's it going Fred? Are we still ok for six weeks?" and Fred saying "Yeah, I think we're 80% there."

A healthy bus number is a side-effect of a culture that avoids the "developer in a room for a month" syndrome. I think it's a more a cultural than a technical issue - a bus number is an attribute of an organisation rather than of a codebase - and the standards have to be set from the top down. Characteristics of this culture include:

• Commonly-understood organisational objectives and business processes, so that developers have something other than a narrowly-technical perspective for decision making, and that they have a framework for discussing pros and cons with non-technical stakeholders.
• Concrete goal setting and verifiable progress indicators, avoiding abstract nouns like "the system" that everyone attaches their own meaning to, verbal reports of "nearly done" or "80% done" understood to mean not done in any visible way, alarm bells going off if a few days go by without objective progress from a developer (new tests passing, new demo version, etc).
• Auditing and accountability: you're not only responsible for doing your job, you're responsible for rendering account of it to your colleagues. Being asked to render account isn't in any way a criticism, it's a means of support and a way of "checking-in" your knowledge to the organisation.
• Curiosity, willingness to support colleagues. Bus number problems are often exacerbated by the reluctance of other developers to help their bus-crash-vulnerable colleague in case they get infected with that colleague's sprawling responsibilities and legacy maintenance chores.
• Informal channels for raising problems and doubts (for example, colleagues have lunch together), and formal processes for logging and escalating problems.

Answer 21

By following a design pattern which governs coding style, conventions, and overall low-level technical architecture. This way everyone codes 'the same way', so if someone new had to come on board, they could just follow the design pattern.

This can be annoying for the creative minds out there (as flexibility is compromised), but it ensures a consistent code base and also promotes consistent aligned unit testing.

To sum up:

• Design Pattern(s) ensuring every developer is conformant to the pattern (you could even use code policy rules in visual studio team foundation to enforce these rules)

• Unit testing which covers greater than 80% code coverage (Which also paves the way for test-driven development)

Answer 22

I think this should be rephrased. A good SINGLE developer shouldn't care about a bus factor. If his project dies, oh well. A good TEAM on the other hand, should have a very low bus factor.

Answer 23

I found this this blog entry, which contains some interesting points:

1. Keep things simple: Keep processes as simple as possible (but no simpler!). This ensures that the processes are easy to maintain and hence easy to teach to others. Simplicity usually boils down to two things: a) using the right tool for the right job, and b)using the most straightforward way to achieve what’s needed. I have seen several processes that are needlessly complicated by inappropriate technologies or use of technologies. To elaborate on the latter, processes are over engineered often for no other reason than to demonstrate the cleverness of the process creator. Avoid creating such Rube Goldberg processes at all costs! An important, simplicity related factor (from the bus point of view) is to use technologies that are familiar to more than one person on the team. This builds in a high bus factor from the start.
2. Document, document, document: This is a no-brainer, but people still think they can get away with “doing it first and documenting it later.” Documentation done after the fact is often less than useful because the author forgets to include some (many?) small detail(s) which, of course, turn out to be critical ones in times of trouble. What should a process document contain? Enough to help someone figure out what, how, where, when - what it does; how it’s run; where it sits (servers etc.); and when and how often it’s run. The documentation should also include some basic troubleshooting information and references to relevant sections of manuals. Another important point is to keep the documentation in synch with the process - i.e. to update all relevant documents whenever the process is modified. This is essential because process documentation is your only guide when the owner of a process with bus factor 1 goes under the bus instead of getting on it.
3. A small word about style is perhaps in order - process documentation should adhere to the 3Cs of clarity, conciseness and comprehensibility. Yes, it is possible to write in a way that achieves all three, although this isn’t evident in my writing. Encourage people to pick up secondary skills: The first two points dealt with process and documentation. However, in the end, it is people who make things happen. Despite well-engineered and documented processes, one can still have a low bus factor if the team doesn’t have skill redundancy. Who’ll look after the databases the when the DBA goes under (or is run over by) a bus? This question wouldn’t have to be asked if someone had been cross-trained in basic DBA tasks. As far as possible, everyone on the team should have at least one secondary skill that will enable them to cover for someone else.