“We specialize in providing professional software development services to clients.” Such a statement will appeal to any potential client, but alas, any applicant-contractor positions himself as a professional. Indeed, if you honestly admit to being unprofessional, then you will not be allowed to come close to any project. But how can a client, who usually does not understand the intricacies of software development, be sure that the contractor really knows his business? If there was a simple answer to this question, then a lot of the money that is now spent on projects that are doomed to failure from day one could be saved.
This article offers the simplest test of professionalism, comparable to the “litmus test”: it lists the minimum set of skills inherent in a good developer, such as Svitla Systems. An inexperienced client should put such questions to the contractor – and he has the right to count on meaningful answers. I must say right away: I compiled this list with the best of intentions. Programs can be developed with a partial or complete absence of these skills, and this can be quite a professional development. On the other hand, even the presence of all of the above does not guarantee the triumphant completion of the project. So let’s say you’re a client looking for a suitable software development contractor. For you, it can be both a freelancer and a company.
You can simply arm yourself with this list and ask the candidate all the questions from it in order. Listen to what they have to say and ask them to demonstrate certain skills in practice. At first, you are unlikely to be able to distinguish a brilliant implementation from a trivial one, but gradually you will learn to do it. The bottom line is this: if a developer can easily demonstrate a particular skill, then most likely he is really good at it.
Minimum Skills
The list of skills is arranged in ascending order of their direct impact on the quality of development. The idea of quality counts on three levels: from your (customer’s) point of view, from the point of view of the end user, and from the point of view of the next developer who gets the source code from the first developer.
Source code management system
This technique has a number of different names: source code management (SCM), version control system (RCS or VCS). It is used to track any changes that are made to the code over time. Using such a mechanism, the developer will be able to know exactly what change was made to the code and when, in which version it happened and who made it. Later, such a change can even be undone. If your interlocutor says that he has experience with specific version control tools – for example, Git, Subversion, Perforce or Mercurial, then this issue can be considered resolved. Have a contractor demonstrate a typical sync-edit-edit cycle and try to understand what he’s telling you. Most developers like to brag about their mastery of version control systems.
Task Tracking
The Issue Tracker (and also the Bug Tracker) is a tool that saves all the requests, bug reports, feature requests, and complaints you make. It can be compared to a trouble ticket help system. The issue tracking system provides the developer with a kind of “action plan” and acts as an objective documentation of your communication with the developer. If you can’t directly access the site’s issue tracking system, have the candidate demonstrate a typical scenario, such as filing a bug report. At a minimum, the developer should provide you with a list of resolved issues for each version of your software.
Continuous Integration
This is a relatively new tool, but it has significant potential. It can also be called an “application build server” (build server). There is also talk of a “nightly build”. We assume that the build of your project will be automated whenever possible. In the case of continuous integration, a new build occurs after each submission of a new portion of the source code to the version control system (we talked about it in the first paragraph of our list). Ask a developer to demonstrate what happens automatically after submitting code to source control. Ask the candidate about the “build time” of your project (or other projects). Build time is the period it takes to get a new version that you can test. If the build time is quite short (say, a few minutes) – ask for a small change to the project and wait for the result. It is possible that your developer will touch not only the topic of “continuous integration”, but also “continuous deployment”.
Questions will pop up related to “staging files”, “build queue”, “test installation” (test installation), etc. That is great! Give him the opportunity to demonstrate “continuous deployment” in practice. You will probably be impressed and the developer will get another chance to trump for you.. e. That’s great! Give him the opportunity to demonstrate “continuous deployment” in practice. You will probably be impressed and the developer will get another chance to trump for you.. e. That’s great! Give him the opportunity to demonstrate “continuous deployment” in practice. You will probably be impressed and the developer will get another chance to trump for you..
Verification (aka testing)
“Will the source code contain automated tests?” Oh, this is a delicate issue. In our business, the expected value of any automated tests is still approaching absolute zero. But, if in response to this question the candidate simply looks at you in bewilderment, this is a bad sign. In the case of a meaningful answer, it is not so important whether “unit tests”, “integration tests”, or even “acceptance tests” are mentioned. More importantly, let the candidate demonstrate to you the implementation of automated tests in your (or similar to your) project. Make sure that the continuous integration server (more about it in the third paragraph) really runs automated tests, and at each build.
Thus, if any component, supported by tests, fails, you will immediately know about it, and you will not have to deal with errors, which appear again and again in each subsequent version (such a symptom is called “regression”). Perhaps your developer will be a true testing enthusiast. And let every hour of his work cost a lot of money – do not doubt that the money for testing is not spent in vain. Think of this as a safeguard against any unexpected future behavior of your program.
During development, the tests themselves are likely to be invisible, since they are used internally. Ask the developer to talk about how they organize test reporting. Perhaps a “test coverage” report is being compiled to accompany the list of tasks (such a list is discussed in the second paragraph)? If a specialist claims to practice “test-driven development” – you can be sure that that he tries to conduct the most detailed tests. Let him show you the merits of this approach and model the implementation cycle of a small change in your project. Perhaps this will convince you of the usefulness of such reinsurance.
Project documentation
All software projects, except for the most elementary ones, contain such a mass of details that a person is simply not able to remember them all, and sooner or later he forgets something. Your developer should have some hands-on experience with storing project information, not just “in code” and “in the issue tracker”. A popular way to implement this requirement is to document the project in a wiki form – it is in this form that the well-known Wikipedia is written. Consider using an online text editor with structured information. If you don’t have access to the documentation tool itself, ask the developer to demonstrate it in practice. Ask for an extract from your project’s documentation, for example in PDF or HTML format. Do not find fault with the aesthetic aspects of the document, its main qualities should be – the convenience and ease of finding the right information. In the end, even handwritten documentation will do, as long as it’s in order and kept in one specific place.
Conventions in source code
Almost any source code is machine-readable. But there are such code samples that are completely unreadable for a fellow programmer, and even for the author himself. Ask the developer about what code formatting rules he uses. Perhaps he will actually present you with written rules that actually apply when creating code. Most programming languages have tools that allow you to check formatting against certain rules. These programs are called “code inspection tools” and are ideal for working with a continuous integration server (see third point). However, some aspects of the readability of source code cannot be checked algorithmically, such as the choice of names or the clarity of concepts. Good developers review their code regularly, critically discussing it with colleagues and suggesting optimization options. And a good client openly indicates the need for code review, even if he himself is not going to participate in it. In the long run, you will soon see for yourself how much this improves the quality of programs.
Participation in the life of the community
Software development is a fast-growing field of activity in which life-changing discoveries occur every now and then – no less than once a year or two. A single developer cannot keep track of the development of all the constantly changing tools, phenomena and opportunities in the field of his professional activity. You have to rely on the experience of a community of colleagues and like-minded people, as well as experienced experts who are ready to share their knowledge. Ask the developer how they interact with the peer community. What (technical) books has he recently read? What books have been studied by the entire development team? You, as a client, may not be able to immediately assess how valuable the books named by the developer are, but this is not the most important thing. As with tests, the list of books read by the average programmer may not be very long. It is important that the development team is sufficiently cohesive and has a common base of technical knowledge gleaned from specialized literature. But the matter is not limited to books. After all, printed books just can’t keep up with the development of the industry! Ask about the technical conferences the candidate attends and whether they are in user groups to discuss the programming language used in your project. How is collaboration organized? Does the developer like to share his experience and findings? By the way, for this it is enough just to maintain your own blog (for example, the one you are reading now). Ask a programmer to show you his blog. How many articles did he publish in a certain period of time, what is the response to them? May be, Is your candidate writing articles for a specialty magazine or even working on a book? And now it will be possible to ask other developers for their opinion about the published materials. Perhaps you have found a true professional – it remains only to congratulate you!
But that’s not all, not all…
This list does not exhaust all the skills, concepts and tools that a good specialist should be able to work with. This is just a minimal set that can and should be supplemented and improved. There are whole sets of skills, such as “clean code development” – it’s impossible to mention them all. Ask about what is interesting to the developer himself. Hopefully, his appropriate bluster and professional slang will quickly convince you that you really are dealing with a professional. And you shouldn’t be satisfied with less.