There are a few questions I find myself asking whenever I’ve spent some time developing or managing a new project. I did this recently, as we’re getting ready to launch Picly (test site here: http://stage.picly.io).
One of the things that distinguishes a good team from a less effective one is discipline: the ability to maintain good practices and established procedures in day-to-day work. This discipline is generally imposed by the team lead, rather than by the team members themselves, who… well, aren’t always motivated or interested enough to create a product or project that can be maintained and evolved.
In one of the chapters of The Programmer’s Black Book, I summarized the most important indicators for building quality software in the form of seventy-eight questions. They’re simple, direct questions that show us where we’re falling short and what we can improve, both in our everyday work as developers and in our profession as a whole.
I think these questions cover the most important things a development team and its lead should consider, starting from the premise that there are no super-gurus (although there are inflated egos, I’m afraid) and no perfect teams—and there doesn’t need to be. What matters is that the business can use the functionality it needs, delivered on time; that we develop with quality; and that more features can be requested without turning the solution into spaghetti that has to be thrown away.
There are many reasons why software rots (software rots). It sounds awful, but the idea is that a solution can almost naturally evolve so chaotically that it’s impossible to improve or maintain. At that point, the only thing left to do is throw it away. I’ll cover the reasons this happens in another post, though there are some good references already published. What I do want to emphasize is that if most of the following seventy-eight questions can be answered with yes, the likelihood of eventually having to throw a product—or part of it—away will be significantly reduced.
If we understand why this happens, surely we’ll make an effort to prevent it. Some of the reasons are quite subtle, though, and their cumulative effect can be hard to notice at first.
Below is the test included in the chapter titled “The Highly Productive Software Developer Test.” As you’ll see, many of these questions aren’t technical; they concern the environment, atmosphere, and way of working we experience, all of which affect our work positively or negatively:
- Is the code we produce adequately backed by tests?
- Does our team have a sufficiently strong culture of writing tests?
- Do we consciously set aside time for refactoring? In other words, do we often ask ourselves whether something can be improved or simplified?
- Do we leave comments such as “TODO…” in the code that we never get around to completing?
- Do we look for ways to apply principles such as S.O.L.I.D. and KISS in our day-to-day work?
- Does the development team work calmly enough, in a friendly and creative environment?
- Is there enough goodwill among team members to cooperate on the project?
- Do our projects have to be finished “yesterday”—in other words, are we always rushing?
- Do we try to work closely with people who are good at cooperating and working in a team?
- Is there individualism in the team, or are there people who find it difficult to work with others?
- Do managers foster a good atmosphere in the team and provide everything needed for it to make progress?
- Do we deliberately apply design principles when we program?
- Do we tend to simplify things that already work?
- Do we feel the need to fill the code we write with internal comments?
- When someone picks up our work, do they have to keep asking us about details they don’t understand?
- Do we strive for mastery in technologies we believe we already know well enough?
- Do we consciously apply the refactoring techniques described in Martin Fowler’s book?
- Do we properly evaluate the external libraries and components used in our project, considering how actively they’re evolving, their maturity, user community, and so on?
- Do we isolate external libraries and components properly so our application doesn’t depend on them too heavily?
- Are we fully aware that more changes will be requested for our project, and that the number of changes will be proportional to its success?
- Do we tend to use the latest technology just because it’s new, without considering whether it’s appropriate (and safe) for our project?
- Do we prefer mature technologies over emerging technologies that are evolving rapidly?
- Do we consider the risks of using relatively new modules, libraries, or components in our projects?
- Are we willing to make substantial changes to a piece of code we’ve spent a long time working on?
- Do we try to preserve a piece of code at all costs, even when we know it can be improved?
- Are we honest with ourselves when we conclude it’s better to start something from scratch than to force new features into it?
- Do we allow more people to be added to the team during a crisis, when deadlines are approaching and it’s clear the work won’t be completed otherwise?
- Do we let our managers know when we’re short of the resources needed to deliver our project successfully and with quality?
- If we lead teams, do we understand that when a team fails, we are responsible?
- Do we suffer from too many impromptu meetings?
- Do meetings regularly run much longer than planned and cover more topics than the agenda includes?
- Do we always work on tasks that the project manager has planned in advance?
- Do we overlook the methodology or good practices during periods of stress or crisis as we try to meet deadlines?
- Does the project manager keep changing their mind?
- Do we have everything we need to do a good job?
- When starting a new project or development phase, do we tackle the most complicated or concerning parts first?
- Do we refactor our work continuously, or only when we happen to remember?
- Do we always keep quality in mind—in other words, do we aim to do the best work possible?
- Do we know the technologies used in the project well enough?
- Do we faithfully follow the methodology from the beginning to the end of the project?
- Do we abandon good methodological practices when we feel pressure?
- Do we work in teams with an uneven distribution of talent, with some people being very good and others very “bad”?
- Is a rigid overall architecture established at the beginning of the project, before all the requirements are clear?
- Is the project’s overall architecture flexible enough to change during development, or is it extremely rigid?
- Is the chosen methodology firmly established, or is it ignored at the first opportunity?
- Is the value of following a methodology properly clear?
- Are the most boring or routine tasks always left until the end?
- Do we care enough that our software product is well made and works—and that it looks that way too?
- Do we put enough emphasis on designing user interfaces that are agile, intuitive, friendly, and elegant?
- Do we often design user interfaces with developers in mind more than end users?
- Do we know many technologies superficially, but very few in depth?
- Do we focus more on learning a little about many technologies than on solving real problems with our software?
- Do we feel the need to use the newest of the new in a development project just because it’s new?
- Does our résumé describe the problems we’ve solved with software, or list a string of technologies we know only superficially?
- Is our work planned ahead of time?
- Is it common to arrive at the office without knowing exactly what we need to do?
- Are tasks assigned to us on the fly?
- Do we face constant interruptions while working?
- Do we have the resources and tools we need to do our work properly?
- Do we regularly work overtime to complete tasks?
- Do we feel that our manager cares enough to help us stay focused on our tasks for most of the day?
- Do we try to reuse sufficiently mature frameworks and libraries when developing our projects?
- Do we make sure the functional parts of the application are adequately decoupled from each other?
- Do we like reinventing the wheel instead of using libraries that already do what we need, because we think we can do it better?
- Do we always try to write code that’s easy to debug and fix?
- Are our solutions impossible to debug and fix once they’re deployed to production?
- Do we spend a very long time working on the same project and using the same technologies we used years ago?
- Do we rotate between projects periodically?
- Do we identify people in our team or department who keep knowledge and information about a solution to themselves?
- Are we absolutely indispensable to a very specific, critical task at our company?
- Are we willing to share everything we do and everything we know best with others?
- Do we review other developers’ projects?
- Do we regularly read development articles about the technologies we use?
- Do we take part in a variety of projects?
- Do we put some form of configuration management in place before starting a new project?
- Is the defined configuration management process followed faithfully throughout the project’s development?
- Do teams of more than two developers practice continuous integration?
- Does every team member understand the importance of faithfully following the defined configuration management and continuous integration procedures?