Google PlusFacebookTwitter

interface segregation but what about our objects?

By on Jul 17, 2017 in Deployment | 0 comments

The I in SOLID stands for ‘Interface Segregation’. This is a fancy way of saying ”splitting apart dependencies”. Basically, an object should not have to depend on more than it absolutely has too. If it does, it may have to be modified when the dependency changes, even if the given dependency has no relation to what the object is using from the dependency. The full extent of the principle can be found here and can easily be found through googling it so I won’t describe further what it is. What I wanted to dive into today is why we’re not better at applying the same thing to our models. I often see models growing out of control in our projects meaning that any time we need to use the object, map it or so, it takes a lot of energy and very easily breaks interfaces. Problem We have a model for a person, a person has a name and an age Next iteration we...

Severity is a priority, or was it the other way around

By on Maj 18, 2017 in Development, General | 0 comments

When you get incoming requests and/or emergency tickets it’s important to be able to classify these properly to know whether you should stop what you’re doing or possibly if you should be doing it at all. This topic came up in my team the other day and at a prior clients we had a pretty good way to classify this to get a priority together with severity. Often you can see these link up 1-1 but not always. Since I’m in Japan I figured I’d try to post this in as well so I’ll update this as soon as I’ve got it proof...

Communication in text

By on Okt 9, 2016 in General | 0 comments

These past weeks we have focused on planning at my client. We’re figuring out the next steps in the product and this requires a lot of communication. As engineers I find that at times we focus completely at our trade. Often though, good or bad, we spend a huge amount of time communicating. I believe we have to do this. We are more often than not, creating something on request. We usually build products on someone else’s behalf. This means that we have to communicate a lot to understand what’s requested from us. Currently we communicate in use cases, epics, diagrams, user stories, tests etc. It is everything from excerpts in mails to page long specifications. What I’ve found (especially since I remote work) is that, what gets written, rarely gets read. We all know this is true for things such as documentation :). Some times the best way to keep secrets is to put...

User stories and use cases

By on Sep 23, 2016 in Development | 0 comments

TL;DR; Use cases are higher level and describes to the user what a feature/story does and the user story describes how the system solves this need. My team is currently fleshing out some new features for the next version of our software and this morning I started thinking, how should we actually do this. We’ve got a rough idea about what we want done but how can we communicate this to everyone involved in the right level. We need to be able to tell our stakeholders what we’re going to do without getting bogged down in details on exactly how we will do it. Not to mention, until we know how we will do it we can’t prioritize and decide which of the how’s we’re going to do. So, how do we put this into text and communicate? Googling user stories and how to write them I ended up instead reading about what differs use cases from user stories. We’ve used the...

EnumerableExtension

By on Sep 2, 2016 in Development | 0 comments

Now I use the enumerable extensions in C# a lot. First(), Single(), Select() is everywhere. However, I’ve found that there’s a few I’m missing and that sometimes they just don’t exactly suit my purposes. So, sometimes I create an additional extension method or two, like the two below: View the code on Gist. TryGetFirst I use because the Try-pattern is nicer sometimes than the if(result != null) pattern. The TryGetSingle is mostly due to the fact that the Single() enumerable extension throws (or at least used to throw) the same message for when there were no items in the list and when there were more than 1. I usually find that if there’s more then one, then there’s an error and if there isn’t one I want to handle that in a different...