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.

Book review “Developer Testing”

Testing is a craft that requires not only effort of a test team. Also developers are obligated to take their share into testing. While wanting to increase the awareness of testing within our development team, I picked up the book “Developer Testing”, written by Alexander Tarlinder. As the title sais, it focuses on what a developer can do to increase the quality of his or her software by testing. In this post I will shortly describe the book and what you could benefit from it.

Read More…
Posted in Books at January 8th, 2020. No Comments.

Getting the most out of a code review

Code reviews are most of the time introduced within a team to have an additional pair of eyes. Developing is a human practice, hence can lead to mistakes. When you’re developing a piece of code, you can miss things like wrong assumptions regarding your design or code that might cause issues. Things that your peer might address.

If you as a developer put your work to review, it feels like that you have to go to a jury and people will judge your work. Although this could feel like this, it is also an opportunity for you to grow as a developer. Other people might have different insights and give you hints and tips to different solutions. It will also catch up issues and typo’s in upfront before delivering.

What does it take to have a productive and good code review? It first starts with good preparation; knowing what the code does and behave before actually starting to review it. Then we can wrap it up and give the reviewer some suggestions that he can look at, without being aggressive.

Let’s go through these steps and look them into detail with some suggestions how to tackle them.

Read More…
Posted in Best practices, Scrum at October 24th, 2019. No Comments.

Tasks and the AggregateException

When running a task asynchronous in an asynchronous environment, you can catch exceptions as you just using asynchronous code. When an exception occurs, C# will catch any exception and put it into the Task that will be returned to the caller. Furthermore, the Task becomes Faulted. The exception will be thrown now at the place where the await is put to wait for the result of the asynchronous call which caused the exception.

This changes however when calling a asynchronous task in a synchronous way.

Read More…
Posted in C# at August 13th, 2019. No Comments.

Passing exceptions between logical layers

Assume you have a layered system, build-up using the separation of concerns principle. We have a UI layer, a services layer and a database layer. The UI layer communicates with a service layer, which communicates with a database layer. As the names describe, the UI layer is responsible for showing an UI to the user, the services take care of main logic of the application and the data access layer communicates internally with a database.

Read More…
Posted in Best practices, C# at July 19th, 2019. No Comments.

Multiple return paths

Some argue that you shouldn’t have multiple return paths within our code. What are the benefits of having just one entry and one exit point?

Readability

You will keep the flow simple by having just one entry point and one exit point where the result is returned. In this case the code will be easy to read: you can simply read where the value is changed and where the end result is expected.

Controlling your object lifetime cycle

The main origin of the argue having only one return path, has its origin at languages like C or C++. In these languages you actually have to allocate memory when you want to use an instance of an object and deallocate it when you don’t need it anymore. If you forget the last one, you end up with memory leaks. Let’s say you create the instance and after that you return a value when some condition isn’t met. In this case, the line where your object is deallocated will not be called anymore.

A valid use: checking preconditions

A valid point where you could enter multiple return paths is at the beginning of a method, where you check the preconditions of your method. If a user of your method passes invalid arguments, you can quickly return a default value then have additional checks in your code.

 

Posted in Best practices, C#, C++ at June 12th, 2018. No Comments.