Developer Viewpoint —Software development isn’t just writing code

Jul 29 · 5 min read
Photo by Randy Fath on Unsplash

Before software can be reusable it first has to be usable” — Ralph Johnson

Developer Viewpoint is a regular section on the blog that involves two developers discussing diverse topics within the IT industry. The discussion takes the shape of a dialogue and in this issue, Ekhor Asemota discusses Software Engineering with Dmitriy Kraevoy.

Ekhor is a software engineer who currently works within the Capgemini Microsoft Team.

Dmitriy is a highly experienced software engineer and architect who works with a broad range of technologies such as C#, ASP.NET, SQL, Dynamics 365, Logic Apps, DevOps and Azure.

Ekhor: The term software engineering is very vague and often refers to a broad range of concepts and as such, loses its meaning. How would you define software engineering?

Dmitriy: Software engineering is a controversial and frequently misunderstood term. There are multiple definitions from simple to verbose. I prefer “Software engineering is the application of engineering to the development of software”. It is simple to understand and defines the essence of the subject.

Software engineering objectives are to make software delivery reliable, predictable, measurable and repeatable using proven engineering methods.

Ekhor: From your definition, it can be inferred that software engineering encompasses several activities. However, it is often common for people to view software engineering as “only programming”. What do you think is the reason for this?

Dmitriy: I believe this assumption comes from the early days. The solutions which we deliver today can be mission critical and complex. Software engineering was introduced to handle this level of complexity.

What we do now is much more than programming; programming is just a small part of the overall process.

Ekhor: Do we really need all the ceremonies of software engineering to deliver robust software?

Dmitriy: Software engineering ceremonies are even more controversial than software engineering itself. There are a lot of debates around this area. Software craftsmanship, for example, is based on a different set of principles.

What matters is the result and the delivered value. Software delivery should be based on a pragmatic approach — something that works well on one project may not work at all on another. How many ceremonies to introduce is more of an art than a science.

Ekhor: Let’s examine software engineering from within the software development team. What if there are some members in a team who hold the view that all of this “software engineering talk” is just a waste of time. How would you address this?

Dmitriy: Like probably the majority of people who have spent years in this industry, I have been involved in projects where unit tests were not written, and SOLID principles were not followed. Most of these projects, nevertheless, were considered to be successful.

What is a successful delivery? The life-cycle of the system does not end when the project is complete, it is only the beginning. Extensibility and ease of maintenance are what make a system successful in the long term.

To achieve this without following good software engineering practices and without a well-established DevOps pipeline, is almost impossible. Test Driven Development (TDD) or code which adheres to SOLID principles will not give faster results, but they will increase quality.

Ekhor: Similarly, what would be your advice when there are team members who want to “over engineer” everything. For example, they want to use only the new “shiny patterns” they just read in a popular journal?

Dmitriy: Every problem has an infinite number of solutions. More complex solutions require more complicated testing, support and maintenance. I always advocate a “fit-for-purpose” approach. Do not introduce complexity if it is not needed, do not create levels of abstractions because the book or pattern says so, do not mix different approaches within the same solution. “KISS” and “YAGNI” are always good to keep in mind.

Ekhor: As we have mentioned SOLID principles, it is only fair to point out that SOLID is only one of many software engineering techniques. Are there similar techniques you would recommend; and why should we care about them?

Dmitriy: SOLID provides a very good foundation. It works well together with TDD or Acceptance TDD. “Well-written” code and good test coverage will simplify further development and maintenance.

Combined with DevOps principles and practices they would facilitate high velocity in delivering required functionality and safeguard delivery quality.

Ekhor: Are these techniques relevant today when most projects either use managed programming languages like Java and C# or package solutions such as Dynamics 365, SAP, Drupal, etc.?

Dmitriy: The delivery process does not change if we use packages or low code solutions. The tools may be different, but the principles remain the same. Software engineering provides a foundation, on which the delivery is based.

Ekhor: One aspect of software engineering that I personally think we don’t pay enough attention to is testing. While TDD tries to address this, I often feel that the industry sees testing as a “bolt on” activity that is secondary to the entire software development exercise. In my view, testing should be the most important part of software engineering. What do you think?

Dmitriy: Testing is very important and frequently an underestimated part of the software development process. Many companies now release into production every few days. Changes are happening all the time; the delivery cycle is now measured in weeks if not days. Fully automated comprehensive test suites are no longer luxuries but necessities!

Ekhor: Some discussions on the internet suggests software development is more akin to craftsmanship rather than the “strict processes” of engineering. Do you think the industry may attract more people by adopting a “less rigid and theoretical posture”?

Dmitriy: Software delivery is a complex process and it is evolving. I can see pros and cons of both approaches and I believe that pragmatism always wins. For me development is a creative process.

Ekhor: What would be your recommendation to both aspiring and experienced software engineers in terms of remaining relevant within the industry?

Dmitriy: Continuous learning is the only way to stay relevant. It is not enough to pickup things as you go along. To be a software engineer you need to have a passion and desire to learn.

Ekhor: Are there any resources which you would recommend to our audience for more information on any of the topics we have discussed today?

Dmitriy: There are a lot of good training courses available on Pluralsight and similar resources on the internet. However, we also should not forget the “old fashioned” approach — books.

Read other stories from the Capgemini Microsoft Team.

Join the Capgemini Microsoft team and find available jobs here

Capgemini Microsoft team

To share best practices, knowledge and experiences of the Capgemini Microsoft team


Written by


Capgemini Microsoft team

To share best practices, knowledge and experiences of the Capgemini Microsoft team

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade