Importance of justification

What should be included in a requirement, user story, issue, bug etc? Obviously things like acceptance criteria, priority, cost estimation (e.g. in story points), mock-ups. However from my perspective justification is the most important element. Why do we need anything? What is the problem? What is the context? What would be the benefits for the … Continue reading Importance of justification

Conducting a recruitment interview

So far I have been interviewing dozens (~30?) of programmers and occasionally testers. Below I am going to present some practices that according to my colleagues and interviewees are very good. Disclaimer: I am working in a rather big software development company. We have a lot of clients and products. Therefore maintainability of the software … Continue reading Conducting a recruitment interview

Do not believe any documentation

TL;DR; Do not believe any documentation. It might be incorrect or you may not understand it. Test everything. MSDN lies A few months ago I was writing some code in C# to get executable paths for all running processes. Generally, I tried the most common approach using BCL: string executablePath = process.MainModule.FileName; However, for some … Continue reading Do not believe any documentation

Silly names and buzzwords in software development

My personal ranking of terms that are in my opinion incorrect or overused: DevOps (as a role): DevOps is about culture, it was not meant to be a role! From my experience, there is almost no (or very subtle) difference between DevOps, Administrator, Operations. Why not sticking to the old good term Administrator?Quality Assurance (as … Continue reading Silly names and buzzwords in software development

High code coverage does not guarantee high quality software

Let's look at an academic example: function CalculateQuadraticRoots(a, b, c) { delta = b*b - 4*a*c d = Math.Sqrt(delta) x1 = (-b-d) / 2*a x2 = (-b+d) / 2*a return [x1, x2] } function Test_CalculateQuadraticRoots() { result = CalculateQuadraticRoots(1, -1, -2) Test.Assert([-1, 2], result) } The code has 100% code coverage, yet it works (without … Continue reading High code coverage does not guarantee high quality software

Professionals say “no”

Today during one of technical meetings, I have learned that professionals are assertive. When something is not correct, they clearly articulate it. What is probably the most important: they say it calm and unhesitatingly. Professional software developers should always be able to say 'no', when management wants to make shortcuts or even hacks. These almost … Continue reading Professionals say “no”