Updating the Guidelines

Next page: Resources and References

It is important to review and update these guidelines based on latest industry "best practices" or "good operating practices", as those practices evolve and as EOL learns how to apply them best to EOL projects.

Process review

Should there be a process for updating these guidelines? A periodic review?
Should there be a "facilitation team" to help those doing software development (not necessarily just programmers) put the guidelines and suggested practices to good use? Such a team would be the natural place to house infrastructure support for things like subversion, git, jira, websvn, MoinMoin and fisheye.
How should we determine when and how the guidelines should be applied to different projects? Should this report document specific adjustments for different groups? For example, CTM and DMG software projects may have different practices, and some SSG practices may not apply outside of instrument developments. Perhaps the point needs to be made that these guidelines should be kept as universal as possible, so they can be applied consistently throughout EOL.

Practice priming

New hires should be enculturated into a project on their first day.[cheezburger] A mentor should guide them through writing production code following the specific project practices chosen from these guidelines (as described in the project checklist/overview). Old hands on new projects should do similar - either be mentored through their first day on a project, or pair-program and mutually discover/reinforce proper practices. These processes can feed into a project-practice iteration.

Action items

If there are some specific action items which should follow from these guidelines, then list them here.

Encourage more use of issue tracking, and if necessary consolidate on JIRA as the issue tracking tool. This does not need to include users at this point, but if we're not keeping track of bug reports and issues from our users, then we're not doing the best we can to be accountable to them.

Blog? Perhaps a shared blog, or a planet gateway to individual blogs, would be a convenient way to hear about what other developers are doing and how developments are going. It might also be a convenient way to log progress and to report on milestones, and the blogs would be available to anyone interested, including managers and other project team members (not just programmers). The blog could be part of a confluence wiki for EOL software development, perhaps migrated from the Software Engineering Wiki.

Open Questions

Issues which were considered outside the scope of this report and deliberately were not addressed.

Should there be guidelines about how to decide whether to purchase and adopt commercial software solutions? This could include IDEs, software analyzers and debuggers, and high-performance compilers. Likewise, should there be guidelines about when to use outside code?

How to publish and advertise these guidelines, and to whom (besides software engineers)?

The single point of failure problem is mentioned briefly in the shared programming practice, but what other practices have been used or could be used? Provide training sessions for other developers? Have another developer write the documentation? Get more programmers involved in bug fix phases to learn by doing? Send multiple developers to support a field project (trial by fire)?

Can anyone name a formal process they have used in the past? What worked well, what didn't? Is there one particular process we should suggest as a model to follow, eg XP, TDD, Scrumm?

As an interesting side question, Google development is restricted to three languages: C++, Java, and Python. Unidata several years ago decided to concentrate on Java. Should EOL consolidate on a few languages?

Next page: Resources and References