6 tips for making an impact in software development

Welcome to The Hüb – a place where professionals generously share their ideas and experience. Our aim is to bring you the big picture and move the whole industry forward.

What is the value of setting concepts when programming? How can you lead a self- organizing team? What is the next big thing in the world of software development?

Pour some coffee, put on some relaxing music and join us for the fourth episode of The Hüb where Milan Starčević shares the valuable experience he obtained while working as Lead Software Engineer at Zühlke.

What is the advantage of software architecture?

Architecture, as we know, is just a useful metaphor that symbolizes the complexity of software development. This metaphor suggests that we must consider not just technology, but also budgets, stakeholders, and our team. At the end of the day, it is the main tool for decision making, and for changing those decisions at the right time.

Software architecture is something you learn all your life because it keeps evolving. What I love is that today we have so many high level concepts that it seems as if architecture is becoming a commodity, something one of my colleagues once remarked. In principle, you do not have to create concepts from the ground up, you just need to combine them. For example, there are many services in the Cloud and what you need to understand is what a service does, and how much it costs. Then all you need to do is to put the pieces of the puzzle together.

Software Architecture has changed so much since the days when The Mythical Man-Month was written, though even at that time the author knew where the story of architecture was heading. Namely, that high-level programming languages would make development easier and faster. This is indeed what has happened.

I am not sure how much further architecture will evolve, as it can go in many directions. For example, machine learning has lately become relevant, and quantum computing, now on the distant horizon, will be a real game changer.

Architectural decisions should and must be made by the whole team. I am not a huge fan of assigning the role of Software Architect. If you explicitly assign it to one person, you might be discouraging the team from making architectural decisions. This might make the team feel a lack of responsibility and motivation for the project.

One could argue that every decision in software development is an architectural decision, some being riskier than others. Traditionally we say software architecture is solving "wicked problems" – those that are difficult to decide because you cannot foresee all the consequences. Yet today there are no longer many wicked problems because it is easier to evolve architecture.

I am a big believer in evolving architecture. I have seen in several projects that changes that used to be hard are today much easier. You need less time, but a good strategy and some negotiating with stakeholders. With this you can even transform the whole product, piece by piece; if that is within the project’s scope.

We often talk about big or greenfield projects, but even for smaller extensions you must think about the conceptual integrity of the system when making decisions. Architecture therefore encompasses everything from folder structure to large system scaling.

In software engineering, architecture and team organization go hand in hand. Note that whoever spends time on team organization will have less to spend on programming, especially when the team count and project complexity are high. But we must not forget that the Tech Lead is first and foremost a developer. You always need to keep up your technical prowess. This is necessary because you do not want to program just for its own sake, but to develop concepts that will be used by the team as "best practice". That is how you can achieve impact by programming as a tech lead.

Software development should be quite simple, that is why team members should reuse from each other and not create a completely new concept every time. Use simple code and a modest amount of it, and you should be able to read that code like a poem. Avoid what one of my colleagues jokingly called "patternitis" – using every design pattern in the book. This is another important reason to know the framework you are using well, so you can rely on concepts that the framework already offers, instead of creating new ones.

How can you start working with front-end?

For frontend, you need to understand the HTTP protocol well and everything that comes with it. You also need to understand different types of web service. You must master and properly understand JavaScript, HTML and CSS. People are often tempted to go the other way around, starting by learning a framework. This can also be a fine approach, but you are a real Frontend Developer only if you deeply understand the technologies you are using. If you do not master these technologies you will end up with less efficient solutions or spend a lot of time solving weird bugs. 

As for keeping track of all the frontend frameworks, I mostly use Angular, but am always open to developing projects in a different technology. Angular 2+ is a nicely designed framework with good abstraction levels. In general, it enables a beginner to start without knowing details of how the framework works. Ultimately, they will have to learn about the depths of Angular so that they are able to keep the conceptual integrity of their code. For example, if you are using reactive forms, you need to use them properly and consistently.

What does a Security Capability Owner do?

In our company, a capability owner is a person who is assigned to a specific area in which they have particular expertise. Such a person tracks emerging trends in that area and the skills needed for future projects. Security capability is primarily about education, and guiding people to think in a certain way, to apply a set of security practices and to use tools that enable them to increase the security of their software.

I specialized in software security during my studies because it covers so many areas of software engineering. You need to understand networks, protocols, both high- and low-level programming and process management. You must know where most problems can occur in software security, and to create a process that includes the whole team and helps them continually develop secure software over the whole project lifetime.

How does one create self- organizing teams?

I am interested in team organization and methodologies. Once you assume a leadership position, you must think about this. I passionately believe in two things. I believe in Agile, but I am not someone who likes to quote The Scrum Guide or other processes. To me Agile represents: "people over process". For example, our company has three core interests: Customer – Company – Team. I try to be in the centre and strike a balance between them all.

The other thing I strongly believe is that the team must self-organize and take responsibilities. Of course, you cannot force responsibility onto an inexperienced developer, you should enable them by encouragement and by having faith in their abilities. If you take such an attitude, then self-organization goes smoothly.

I will go even further and say that in the nine projects I have worked on at Zühlke, none of them shared the same process, even though they shared the name of Scrum or Kanban or Scrumban.... Every time I begin a project, I try to understand how the stakeholders and the team see existing roles and processes. Then in the Storming stage of Tuckman's stages of group development, the team will create a common view. From this view a process emerges. This process will of course evolve over time as the team matures or changes. Moreover, there is no single way that you can apply to every project, no matter how much someone wants to blindly stick to Scrum.

I really try not to control my team unless a specific situation occurs where I need to direct resources. Empowering your team is crucial. I have never even thought of giving orders, rather steering towards finding solutions. It is still fascinating to me how much I can rely on my team.

When I was younger, I always thought that the tech lead knows everything and controls every single detail, but in truth I have realized how many details I do not know. The most important part is that people are motivated and are not blocked. For me, priority number one is to avoid a blocked team member, which can be bad both for team motivation and for the customer.

Should product value be thought about in advance?

You need a certain mind set for this, and it develops over time. To achieve it, you need to communicate about all parts of the project and be transparent with the team. You must also encourage the team to think about the customer’s needs. The main challenge is that, depending on the customer and project, this may be harder or easier to achieve.

We currently speak of customers because we are operating in a market economy, but in any type of economy we would have to contribute to society in some way. Any economic system needs both insurance projects and projects for giant telecommunications companies that will service millions of users. Our task is to work in a way that will add value to either.

It takes enthusiasm and a broad perspective to achieve this effectively. The way to add value is to think about why the customer wants something before implementing it. Intention is always important. Depending on how much experience the customer has in collaboration with software companies, their solution may have more or less technical merit.

Yet we often find that the solution the customer wants is not the solution they need. You must challenge the customer, but in a diplomatic way. The customer will always be happier if you discuss your way towards a better solution.

What is the future of software development?

I am interested in quantum computing, although it will never become fully commercial. We will not use it for table grids or cat videos as it gives no performance benefit for such types of task. but it does provide incredible performance benefits for extremely complex calculations. For example, it can be used to predict the weather more accurately or to improve protein folding calculations. It is only a matter of time before we reach the critical number of qubits to achieve "quantum supremacy" – the point where a quantum computer can solve a problem no classical computer can.

On the other hand, it will mean a giant leap for an individual programmer since it is based on a completely different architecture and computer organization. It also includes quite different mathematics, which you need to learn.

What is also interesting is that the power of quantum computing will be so great it will break current cryptography and significantly threaten software security. This means it will be heavily regulated in the beginning, or at least until quantum cryptography becomes part of all computer systems.

There are initiatives to provide quantum computing commercially, like Microsoft intends to do with Azure. You can use Q# to make a quantum program that will currently be executed through a simulator on a classical server. In the next step, all Microsoft needs to do is change the underlying hardware when it is ready. In this way you can easily make quantum calculations using Q#.

I find this fascinating because it is like something out of science fiction, and yet it seems to be approaching in our not too distant future.