The purpose of software development and its associated primary capabilities

The purpose of software (product) development is basically to create a product, timely, that is useful, hopefully pleasurable, secure (this is perhaps not an universal) and maintainable (because we aim to build on top of what we have already delivered).

To be successful in fulfilling our purpose we need to i) know how to manage (=gather, analyze, tweak) our users' requirements, ii) build in quality (="0" errors), usability, security and maintainability, iii) Be great at deployment/roll-out and iv) provide excellent service.

All other capabilities are secondary to these. 

 

P.s.

I am aware of that the cost aspect is missing here and of course someone has to keep the cost-revenue in check, but that is just one of many external constraint, other such constraints are the skill-set of the team you have, and the maturity of your users and their environments, and more.

The hiring process

I have probably conducted several hundred job interviews, ended up hiring close to 100 people. The process starts with a need, this spawns an advert, then the interviews, negotiations and contract finalization. I wanted to record some 'lessons learned' here.

The reality in Iceland is that we get a manageable number of applications, meaning that it is possible to read through them all and before deciding on whom to invite to an interview. The number of invitations are normally between 3 and 20. The number of interviews rounds are 3, but I have also done 4. Usually I try to squeeze the whole process into 2 weeks when possible.

The first interview - why you?

Initially I did ~1h first interview where I spent ~30min going through introductions to the company, products and processes. Recently I have shortened this to 20-30min by sending out a (abbreviated) introduction, a copy of the advert text (required skills etc.) and the interview questions/topics I would like to cover. This allows me to shorten the interview and put the focus on the applicant. At this stage, as I see it, the applicant is 'proving' (s)he is a good fit for the position.

The latest batch of interview questions I use is:

1. Something unclear regarding the invitation text?
2. What makes you interested in the position?
3. Where do your strengths and weaknesses lie w.r.t. the skill requirements and job environment?
4. What are your professional ambitions?
5. How do you think your coworkers would describe you?
6. Other questions from me related to the CV/introductory letter.

It is not important to go through these questions in order and in many cases when the interview 'flows' they get answered without being specifically asked.

I usually get someone to sit with me through this interview. I have been assisted by tech-leads, project managers, product managers, developers, testers, and HR personnel. It can help with the flow, but also getting a second opinion after the interview. I keep notes during the interview. Use a simple grading mechanism, giving a score of 0-10 for: Drive, Collaboration, Technical strength. It is important that the applicant has some drive, it can be for technology, the domain or best practice; can collaborate within a team; has the necessary technical capability. But I also look for fit w.r.t. the existing team members and our projects' requirements.

The second interview - why us?

The second interview is focused on issues that the first interview left unclear. Could be the need to drill down into certain technical skills or people skills. It is also an opportunity for the applicant to ask questions. But here the tables have slightly turned, now we are interested in hiring the applicant and we need to 'prove' that we are a good fit for him/her.

Usually I will get the helper from the 1st interview to sit in with me again. Before the interview I will have either called myself or asked HR to call the references for a basic background-check that goes mostly to character reference.

This interview does not have known list of questions, it can take 30min to an hour.

I will ask after both interviews if the applicant is interested to take the next step in the process and explain what time-frame I working with.

The third interview - how much?

Previously I would take the contract negotiations, but now this is done by the director of the department, I might be present or not during this interview.

Closure

I think it is important to send an email to those who did not get the position. Those not invited will get a rather standard email, but I will try to have a personalized email for those I met. The intention is not to spur a further discussion on merits, more an attempt to give the applicant a proper closure.

Development manager: where should you place your attention?

Your attention is a limited, valuable, resource. With attention I make the distinction between placing continuous attention (being pro-active) vs. temporarily placing your attention where needed (being re-active). So the question I would like to investigate is more specifically: on what to keep continuous attention.

At a high-level it can be said that the development manager has two (related) objectives: i) maximizing throughput of new product functionality and ii) minimizing product quality problems. 

Mapping your attention to those objectives results in:

i) Be involved in solving problems the teams face during development. I find the best vantage point here is to be involved in DevOps because they are all day solving these (technical) pain points. But also be involved in the developers' discussion on architecture, processes and tools to spot the technical debt that is holding them back.

ii) Be involved in solving the quality (correctness, usability, efficiency, reliability, integrity, adaptability, accuracy, robustness¹) problems that surface in the final product. Here the best vantage point is to be involved in release testing and monitoring of the product in production.

---

Note 1 What is missing: continuously paying attention to people and team dynamics. Frequently the problem analysis will reveal problems related to people (e.g. training), teams (e.g. communications) and processes (e.g. unclear responsibilities) and then you move your attention to those (re-actively) to solve the problem. When the problem has been solved your attention moves back to the main objectives. 

Note 2 This is my current thinking, I acknowledge the view (HR-take) of cultivating people and teams will lead to great products. That approach requires a certain leap of faith and does not fit as well with my engineering problem-solving outlook.

---

1 Taken from McConnell's Code Complete^↩

The roles of the development manager

I have had the title of development manager now for 13 years. It has had slightly different meanings throughout this period; I find it best to talk about different roles I have served while having this title. I think the following list of roles is fairly complete, although the naming can be improved upon.

• Project manager - I have lead various business (revenue generating) projects. This is strictly not a role for the development manager, but I belief it is often the case that some project management work accompanies the title.
• Process maker - the development process needs to be designed and deployed. It is important to be proactive, but the work is necessarily done in cooperation with all stakeholders.
• Process guardian - this is the process policing, making sure the processes are followed (teaching/guiding/finger-pointing). This also includes managing internal documentation/data.
  
• Infrastructure owner - responsible for keeping the IT infrastructure operational (and cost effective). Including the CI/CD tool-chain and dev/test/staging environments.
• Release manager - making sure that release schedules are kept, enforcing code-freeze dates, managing release testing and delivery/hand-over to Service.
• Human resource manager - hiring, firing, training, conflict resolution, setting up teams, office managing (w.r.t. seating, equipment)
• Dev(sec)Ops manager - enabling team decoupling and team empowerment.
• Liaison to external developers - providing test environment and managing communications.
• Liaison to intra-company dev-teams - facilitating knowledge transfer with dev-teams in other departments.
• Technical manager - facilitating and (sometimes) initiating discussions on architecture (monolith to micro-services), framework (angular, vue, react, e.g.) and tool selection (UI libraries e.g.). 
• Asset manager -  this is perhaps covered by the other roles, but I think worth mentioning. This is the management of (digital) assets of the department, such as data in shared network drives, in wikis, in issue management tools, videos (Stream), collaboration platforms (Teams/Sharepoint), and software licenses.
  

Making (new year's) resolutions - a framework/categories, take II

Approximately a year ago I posted on this same subject. Now a slightly different take, perhaps a simplification.

 The following categories are useful to setup the right goals (resolutions):

• Basic skills ('the engine') - the foundation that the rest builds upon. I need to keep the physical and mental facilities well maintained. In my case I will be focusing on running and meditation.
• Mastery. It is important for my self-worth to gain mastery. I actually think I have done so in many subjects but I have not capitalized on it yet and my primary focus will now be on identifying it.
• Purpose. 'Higher purpose' if you like. Last year I focused on my 'micro' environment (friends & family). Now I am considering on expanding, adding a 'macro' component related to nature and fellow humans. Not going full-on altruistic, but in that general direction.

I would like to focus on a certain values to guide me through the day-to-day decision making. I will keep the ones I had last year.

P.s. Perhaps you can see a similar pattern here to the one in Drive by Pink: Autonomy, Mastery, Purpose.

Evaluating the health of a software development unit

[ Out of scope (but extremely important): Are we producing the right thing? ]

If I were to evaluate a software development unit, I would ask the following questions:

(measures of current health)

1. How long does it take after an new idea is conceived until it starts being used by end users?
2. How long does it take until a change request or a bug is discovered until it is deployed?
3. How consistent are these times?
4. How many errors are being deployed to production, and how are they discovered?

(measures of continuous/improved health)

1. Are developers growing?
2. Are processes being improved?
3. Is technical debt managed?

 

To probe further as to where the areas of improvement lie, I would investigate the following key attributes of the product:

1. Maintainability (e.g. coding standards, test automation, documentation)
2. Release management (e.g. CI/CD, traceability, planning, configuration mgt)
3. Risk management (e.g. single-point-of-failures, technical debt, regulatory compliance)
4. Quality management (e.g. testing, code reviews, repeatable procedures)
5. Serviceability (e.g. logs from production (errors, statistics), handbook, su configuration)
6. (Security (e.g. scans, audit, access mgt, policy))

Making (new year's) resolutions - a framework/categories

How should one go about setting (New Year's) resolutions? I tried last year to set myself some goals, it was useful. They were not overly ambitions but gave me some push to complete certain tasks which gave me a sense of accomplishment at the end last year.

So this year I decided to give it another try, but this time I went about it more methodologically (big word!). After several iterations I ended with the following categories. I am pretty satisfied with the categories, think they create the right framework for settings goals with the focus on the long term.

Two categories go to creating a well functioning 'machine' necessary for everything else:

• Physical well being/performance (ísl. líkamsrækt).
• Mental agility (ísl. hugrækt).

 One category goes to purpose or basic need:

• Connections (family and friends in particular, those that will last to old age).

 One category goes to security:

• Professionalism

The last category goes for guiding the decision making (for this journey to old age)

• Values.

Setting up the role of testing

We have tried assigning testing to three different roles: The developers themselves, a tester test-in-the-loop, a quality assurance officer.

Presupposing that manual testing is a good thing, we have discovered pros and cons for the different setups.

Developers as testers

Having the developers cross-test each others' issues has the benefit of transferring knowledge of the code, of best practices and of improving the art of communication [arguably this same objective can be fully covered with peer-reviews --Ed.].

Developers however are not equally good at testing and probably not as good as a trained tester. It might not be the optimum use of resources. Some even find testing boring and that it breaks up their coding-flow.

Tester in-the-loop

Taking the task of testing from the developers and placing it on a dedicated tester has the benefit of localizing the responsibility of the testing. A tester puts up his/hers own testing environment, and improves his/her processes through greater exposure to testing. The tester has a slightly different approach to the issues, seeking out those special corner cases that lie off the happy-path.

There is a danger of that the developers might grow sloppy, assume that the tester will catch all their errors. And if the throughput of developers and testers are unbalanced, bottlenecks can develop.

Quality assurance

Zooming out, what testing needs to provide is a bug-free customer product. So ultimately what is most important that is tested is the delivered functionality of the product. This reflects back on how requirements are specified, in particular that they are testable. Keeping issue testing with the developers and higher level functional testing with the tester takes the tester out of the loop and places him/her on a parallel track with the developers.

Errors however typically surface later and in Scrum often during another sprint. This of course can be costly and makes tracking issues and burndowns a bit more tricky.


The verdict was not in when I left my last employment, but my feeling was that testing should not be a reactive role (in-the-loop only) but more of a proactive role, and that the tester should be able to proxy the product owner to some extent.

Managing and leading software product development

I have been contemplating the roles of the development manager and the product manager in software development. In particular who has what responsibility?

I recently read something that resonated with me, that leaders are needed to bring about changes and managers are needed to create order out of chaos (complexity). The point being made was that both roles are legit, but require different skills and have different end-goals. The tools of the manager are processes and structures while the leader uses motivation through values and emotions. The goal of the manager is to accomplish the plan and that of the leader to achieve the vision.

In software development it is necessary to decide on doing the right thing and then do it right. To achieve this we both need leadership and management. But how is that best put in place? It is tempting to consider this best done by having a leader-manager. I, however, think it is generally too much to ask for in one person (even though they no doubt exist). In my view the role of the development manager requires more management than leadership, and that the opposite is true for product management.

Development managers should not be pure bureaucrats without vision and the ability to motivate people. They might have the goal of bringing structure to the work but they will not succeed unless what they propose is accepted by the organization and the teams in particular. To accomplish this they might need to find novel solutions and be strong in communicating and negotiate for those. The development manager must not buckle the leadership of the product manager by wielding his official authority (embedded in the org-chart).

What I am getting at is that I don't think that management serves the derogatory conjugation it has had. Leadership and management are both necessary ingredients to successful software product development.

Team structures

The last 11 years we have tried out different setups for the development teams, looking for the one right setup. Actually, now, I think the right approach here (borrowed from others) is to address team structures as a product development. In particular, to do incremental adjustments ('developments', 'experiments') a keep track of these through release notes and retrospects.

This is an attempt to (posthumously) create these release notes/version history.

Version 1

We were three developers and we split the responsibility based on architecture. There was no over-all lead, but we had an IEEE requirements document that we with others had created.

This was a time where responsibility was very clear and code-ownership strong.

Transition driver: It did not make sense to drive all projects with a single developer owner, it would be too slow. New functionality needed to be implemented by a group.

Version 2

We instigated Scrum, we had the product owner and scrum-master roles. A single team.

I think everyone felt good about having clear task lists. Also clearing responsibility for non-code work, such as doing meeting notes, setting up and maintaining the development stack, taking budging decisions.

Transition driver: We started a new code-base, a new issue tracking project, and dedicated split of the developers. But kept the single Scrum team structure. The thought was that it would create too much over-head having two teams, also we thought the knowledge transfer would be best served for both groups to continue working as a single unit.

Version 3

It became obvious that during planning, demo and retrospects half the group kept silent while the other group went through their development and visa versa. Time was being wasted, people were bored. So we split into two Scrum teams although keeping a single product owner and scrum-master.

Transition driver: We started getting more and more load from the service department and we were starting seeing more customer specific development projects. We started out by allocating fixed amount of time and a dedicated developer for 3rd level support issues. We called this role "batman" at first and later "the hat", it rotated between the developers, one having the role for the full sprint.
It was rather artificial allocating a fixed time slot for 3rd level support since it was rather unpredictable how much time would be needed. Frequently this would mess up the burn-down chart and could deteriorate the commitment of completing sprints.

Version 4

We created a specialized 3rd level support + custom development team, called Quicksilver. We pulled out all bug and custom development issues from the Scrum boards and put it on Quicksilver's Kanban board. We populated the team with the two most senior developers. They also got the go-ahead to do the refactoring they thought necessary to ease the future maintenance burden.

Transition driver: The developers on the Quicksilver team resigned. 

Version 5

We restructured the teams into three. This was actually the second attempt where we went from one product owner to three. We discussed quite a bit if we should do this split based on code-bases/architecture or if we should try to do it based on cross-code-base features. The first option won because we thought code ownership was more important then having more flexibility in creating teams around end-to-end functionality. We were still doing quite allot of maintenance and that usually meant going into closely contained areas of the code. However, the latter option has a greater appeal to top-management because they figure that it will give them greater throughput of new (sell-able) features.

There are some versions missing, one is where we when for the first time from a single product owner to three. And first placing them within the teams and later moving them into the sales department putting greater responsibility on the teams. The distribution of responsibility between product owners and the teams is a topic belonging to a blog of its own.

Also missing are our attempts in incorporating testing into the development, by letting the developers do it, to having a tester picking up issues as they complete within the sprints, to have complete sprints tested. This is also a topic that requires a dedicated blog of its own.

Lastly, there is also how the team organizes its work internally. Should everyone be able to do everything, or does it make sense to have some specialization, if, then to what degree? We have done some experimentation here as well. Blog++.