Software Development as a multidisciplinary endeavor

Last summer I came across an advertisement for a teaching assignment at a swiss university for a module called “Software Engineering Basics”. I applied and was even invited to an interview, but eventually they chose another candidate with a track record in education. But even if not successful, the application process proved to be a valuable opportunity for learning and self-reflection. When I applied, I knew of course that I lacked the teaching background, but more importantly, I had to ask myself whether I had the necessary domain expertise.

At that moment I had been a technical business analyst for six years, and before that I had been a team lead for six years, so my job title had not actually been “software engineer” for twelve years. Was I qualified to teach a class on software engineering? Or would the developers in my team just laugh at me?

But what is software development? And is it only done by engineers?

I was fortunate to start my career in 2001 at sd&m - software design & management, a german software project company which unfortunately does not exist any longer because it has been bought and fully integrated into another company. They did not sell software products but software development projects and they relied on the customers for business domain expertise. The company’s employees were all generalists with a university degree in computer science, mathematics or some closely related engineering field. Except for some managers and architects, they were all called “software engineers” even if they were assigned to all phases of the development cycle - then usually very waterfall: requirements engineering, design, implementation, testing, documentation and roll-out.

When I later joined Avaloq in 2008, the situation was a bit different. There were “developers”, “business analysts” and “managers”. The company was very technology-driven and the developers were deservedly proud of their work. But some of them crossed the thin line between pride and arrogance: They would look down on business analysts and did not have much respect for managers anyway. Maybe this was a part of the pattern described by Vikram Chandra’s reflection on macho culture in the American software industry in his great book Geek Sublime.

Fortunately, this has changed with the agile transformation which has swept through the industry in the last years. Scrum promotes cross-functional teams whose members are all called “developers” even if some of them are mostly analyzing, testing or documenting rather than programming. That’s a positive cultural change because it recognizes the fact that software development is more than mere coding. Some universities have started to acknowledge this and create more interdisciplinary computer science tracks like the iCompetence programme at the University of Applied Sciences and Arts Northwestern Switzerland.

Today I am a product owner. That’s one of the only two roles (or accountabilities) which the scrum framework knows besides developers (the other one is the scrum master). But what’s my professional purpose other than developing software? The term “filmmaker” usually refers to the director or producer, not to the person actually holding the camera. In the same sense, I will always consider myself a software developer, even if my contribution is not in writing code but in identifying customer requirements, reconciling stakeholder priorities and maximizing value. That’s why in my linkedin and twitter profiles, I call myself “agile software developer and product owner”.

A related thought concerns the topic of diversity, for example gender diversity. One way to promote women in tech is to get girls passionate about programming. My Avaloq colleague Lara and her team do a great job introducing swiss schoolgirls to coding with their non-profit organization GirlsCodeToo. A complementary approach is to open software development teams to profiles other than programmers, for example UX designers. This will automatically attract a higher percentage of female applicants. And the professional diversity will be beneficial for everybody: As they work together in a scrum or kanban team, engineers will absorb some design thinking over time while designers will start to think a bit like programmers (abstract, functional, object- and service-oriented).

Software development is a multidisciplinary endeavor. That’s why I still love my job!