What I’ve learned working at a startup

Within my previous employer, I worked at a startup company, where we created our own hardware, the software that addressed that hardware and a cloud environment. Before that, I once also worked at a startup, where the product contained a video conference application. Taking those experiences into account, I want to look back what I’ve worked during working within a startup.

Read More…
Posted in Uncategorized at December 27th, 2021. No Comments.

Personas

Agile encourages building software with the end user in mind. It will then help to have a clear and common understanding of this end user within the team. Therefore you can use a so-called persona. Personas represent fictitious people, based on the teams knowledge of the end user. Within this persona you will together write all the details that are of interesting when defining the user stories within your project.

Read More…
Posted in Agile, Scrum at July 27th, 2021. No Comments.

The Arrange, Act and Assert pattern

Besides writing unit tests, it is also important to be able to maintain them. To improve the maintainability of a unit test, it is important that you can easily see what it is trying to test and how it does this to accomplish this task. To improve the readibility of your unit test, you can use the most widely accepted pattern within unit testing: Arrange, Act and Assert (AAA) pattern.

Read More…
Posted in Unit testing at May 1st, 2021. No Comments.

Key takeaways of Robert C. Martin’s book “Clean Code”

Since I see writing code as a craftmanship, I’m also very keen on writing high quality code. In the beginning it might take more time to write your code with a high quality, but in the end this will pay back. For sure the bigger a project becomes, more time it will take to add or change functionality or fix bugs in poorly written code.

When it comes to high quality code, of the aspects that come to mind is that it’s clean code. Clean code helps your team to write and maintain in an efficient way your code base. What properties must programming code have to become clean? Robert C. Martin (a.k.a. Uncle Bob), describes in his book Clean Code – A Handbook of Agile Software Craftsmanship” a number of aspects clean code could have. In this blog, I want to discuss the key takeaways I found within this book.

Read More…
Posted in Best practices, Books at April 14th, 2021. No Comments.

Best practices when using constructors – Redefined

In an older post, I suggested that constructors never should call methods, which possibly can throw exceptions. What also that blog entry explained, is that this idea mainly came from unmanaged languages like C++, where you could easily introduce memory leaks when a constructor throws an exception.

I however came back from that idea, since it also pollutes a lot of your code having to have initialization methods. You add hereby a unspoken contract that, after calling the constructor, you have to call the initialization method in order to use the class properly.

Read More…
Posted in Best practices, C# at December 1st, 2020. No Comments.

Do we need need software architecture or even software architects?

A lot of projects struggle with the fact, when and how much time needs to be spend on software design and software architecture. Although these are two separate things, they are entangled with each other.

I once had the discussion with a software developer that no time should be spend at all on software architecture. To him writing down software designs and architecture where not needed at all, it would turn everything into concrete. The design and architecture would grow naturally while coding. Assuming that, architecture and design would imply that once written, you never could change it. As we will see later on, leaving out the design will even lead to software that can’t be changed later on.

On the other side, there are projects where pages of documentation regarding the architecture is described. To find out what the good balance is and when to spend time at design and architecture within Agile, I started to look what exactly the two area’s tend to fulfill and how they could be embraced by Agile.

Read More…
Posted in Uncategorized at September 30th, 2020. No Comments.

Moving from RhinoMocks to Moq

RhinoMocks is a framework for creating mocked instances, that can be used within unit tests. Since the framework is not to be maintained anymore (last version was in 2010), you can’t use RhinoMocks for example within .Net Standard or .Net Core projects.

A project I was working on was having the same struggle; we had quite a large set of unit tests that where using RhinoMocks. For several reasons, we decided to migrate our projects to .Net Core, which made it impossible to use RhinoMocks anymore. We decided to switch to the Moq framework. In this blog I summed up the most used RhinoMocks constructions and how to port them to Moq.

Read More…
Posted in C#, TDD, Unit testing at June 29th, 2020. No Comments.

Increase your learning with “How to read a book” from Mortimer J. Adler

I always struggled with ways how to get the most out of reading a book. I read quite a lot of non-fiction books, both regarding software development practices and soft skills, but I wanted to have more tools to really absorb the core ideas of a book and be able to reproduce them. A lot of people struggling with the same issue, recommended the book “How to read a book”, written by Mortimer J. Adler.

Read More…
Posted in Personal growth at May 12th, 2020. No Comments.

Negativity in a software development team

Some people tent to spread this negativity along within project teams. Negativity is a bad thing, it drains down the effectiveness and joy within teams. These persons complain constantly at all things, that everyone is wrong, everything sucks and they only know what should be done differently. And off course –seen from their side– they are nothing to blame for, it is the rest that suck.

This kind of negative behavior within a team is a disaster for any team. As Napoleon Hill quite frankly states it, “a bad mindset attracts a bad outcome“. This is quite easy to explain; think you just bought a red car. Now when you look around you, you will think you will see more red cars then before. The reason for is, that our mind will filter out everything where it is focused on. The same is true for having a bad attitude within the team. It will affect other people, and people are beginning to lose confidence in the goals that are defined within the team. What is the reason for this kind of behavior, and what can you do about it?

Read More…
Posted in Personal growth at March 31st, 2020. No Comments.

Defining user stories, minimize the cost

It is up to the Product Owner (PO) to exactly define what he or she expects from a user story within the Definition of Done.

It is up to the team to challenge the PO to have a proper defined user story.

If in the sprint review the PO isn’t satisfied with the end result, saying he or she expected more, the PO is accountable for the result.

On the other hand the team had also to challenge the PO to ask for what he exactly expected from the story.

Both PO and Team are involved, so both are responsible. If the first one doesn’t take the right action, the end destination of the team is very unsure, so changes are big the result doesn’t fit. A PO who has never got time to answer the questions of the team, isn’t a good fit.

If the team fails, they can be blamed asking the wrong or lack asking of questions. Both faults will come at a cost. But be sure you minimize the costs.

Posted in Agile, Scrum at February 3rd, 2020. No Comments.