Identifying core values

Those who have worked with me have most likely heard a few times and probably also got bored by me saying we have to establish a core set of common values before we do any code writing. What I mean by that is that you can’t have a team work in the same general direction without the team actually believing in the same things. Take a thing like being test driven. If you have a split in the team and not a common consensus of wether or not automated testing is good or bad for your team and your product, you’ll end up having tiring discussions and not establishing a climate for establishing a good culture. Worst case; you might hurt your velocity directly by not adressing a bunch of the elephants in the room and over time establish a declining velocity and not notice that it is declining.

Elephants

Yes, there always seem to be an elephant in the room. And they are so hard to get out of the room. Subjects that are impossible to discuss, because you really can’t get reach an agreement. Every place I’ve been to have these, and in my experience, there seem some be a tendency to more than average in software development. I think this comes from a bunch of reasons, but in my experience it boils down to not adressing the underlying issues and also in many cases, really understand why we go to work. In our industry there are some elephants seem to be quite common, things like my favorites; performance and the “keep it simple stupid”-principle. Performance is by some the trump card, whenever a discussion gets out of hand, you might run the risk of this card; hoping it will kill the discussion and we can move along.


Business Value

Why we as developers go to work is something that can be hard to remember. Our job is to add business value to the place we work. It is so easy to forget this fundamental thing and end up doing things that is not related to this, often based on an established culture of developers having the ability to just ignore this fact. By having the power to create something in code makes us experts in our fields, we do something that not many people understand what is. This power comes with great responsibility, we should not abuse this just because we want to do something exciting. Its easy to bullshit a manager into thinking that using technology X will solve all problems, while you could have done this with a different approach in shorter amount of time but you never got the chance of trying out X. Don’t get me wrong, we should always look at tools that actually improve our productivity or helps us get our business value done more accurately or delivered faster or better. Just don’t make up excuses to get to try it out to get it on your resumé.

Lack of understanding

Lets face it, not everyone wants to learn new tricks all the time. And that is actually fine. Being conservative to change can help balance out those who wants to change everything all the time. That being said, there are also those who are conservative because its convenient, because it suits them to not necessarily go in the right direction and hinders development and moving forward. A great way to protect your own job for someone who has been there since the dawn of time and really just want to continue doing the tasks that has been mastered. In our industry I think you’d be crazy to even try to want something like this. Our industry moves quite rapidly compared to most others and knowing only things that belong to the past is not necessarily a benefit. I think this is also important to understand for some of the elephants in the room, people protecting themselves; they just don’t necessarily understand the new ways of doing things and don’t have the full motivation to actually bother learning it. A good manager should be able to pick up on this and make sure the team is motivated and keep the risk down for the company by actually facilitating for learning.


The User

Who are these users we hear about. Adding business value is good for business, but not thinking about the user and keeping them close could be a disaster for business. So even though you think you’re adding something to your system that you believe will add business value, the users might not want it because you made it in a way the users won’t understand. This is something I see all the time; developers making software look like their development tools and thinking the users will just intuitively get it. Heck, I’ve done this myself on numerous occasions. Its like we get tunnel vision, thinking that everyone thinks like us. They don’t! We are possibly the worst frame of reference for what a user wants. This is one of the things that I think brings more elephants in the room that are not up for discussion. Because we’re used to do something, that wasn’t good for the user, we should just continue down that path.


Being pragmatic

This I hear a lot, and it gets presented as an accusation, as if one is not pragmatic. Short and simple; it is an abused term. It is something that gets twisted to fit as a trump card and thrown on the table to stop discussions. It doesn’t really reflect a value of any sort, its just a way of hiding any core value of actually bubbling to the surface. Its often related back to the “keep it simple, stupid”-principle and is just an instrument used to belittle the other person(s) in the argument. I look at other professions whenever I encounter things like this and ask my self, would they throw this card — ever? Take a plumber, would he pragmatically drop putting in a pipe or even worse pragmatically decide to not comply with building regulations. We can do much better than this. The KISS principle is a really good example of something that has completely different meanings depending on the person you talk to as well. For some this would mean; “… put everything in a stored procedure in the database…” type of KISS, while for me it means I adhere to the SOLID principles amongst other things. I don’t like these terms – they don’t bring anything positive to the table.

Core Values

Back to the original intent of this post; establishing core values. This is not an easy task, it is something that can take a while and it is not something you delegate to one person and hope it solves everything. It is a team effort. The team has to do this together and they are going to have to work together to get the wheels smoothly running. An approach that I’ve had great result in slight variations with, is to let every team member write down on three post-its the three most important things to them. One is not to discuss the items with anyone else, the items can be anything related to what the person consider important to be able to do their job. Every team member has to do it themselves for themselves. Put this up on a wall and let every team member present the case for their items and what they mean. You then optimize the wall by grouping the things that are the same. We now want to cut the list down, we can’t have all the items as our core most important values. Then you give the team 3 votes they can distribute on the things they now find the most interesting with the knowledge that we’re not keeping them all — chose wisely. You should now have a ranked list the things with the most votes are more important and you do a cut off at the number of items you decided to keep. I usually tend to keep it at 10. With smaller teams you might consider increasing the number of post-its and votes, so that you get more than your cutoff, even after grouping. A variation of this that I’ve used was after a disaster of a release at a company were we had a yearly release-cycle. After the disaster and weeks of firefighting I put the team together and asked them to come up with 3 post-its each for how we could make the next release even worse. This triggered something very interesting, people got really creative and every one had great ideas of how to really sabotage the next release. We then voted for the things we found most relevant and that we wanted most to do. We then took the list and we converted it into things we should not be doing and then had a cut off of 10 items that became the law of the land for the development team.


What you now have produced is something that can kill the things used to kill discussions, you have a list of things you all have agreed upon is important. It is the compromise, the things that you as a team believe in. Whenever nonsense arguments are being thrown into the mix, the different trump cards or elephants that sit in the room, you can refer back to the list.


Sometimes it is not clear cut what things mean, and you can end up having discussions about the meaning of it all. Try to capture what people are saying when presenting their post-its, put this in writing and get the team to read through and commit to this. But even after doing that, it might be hard to understand. A tool that can help with getting a common understanding is doing pair-programming as part of how you work. Circulate who pairs and start building the dynamics into the team. You end up discussing some of the items on the list and you will eventually break down barriers and create a team that at the very minimum executes more in unison. Typically the elephants can actually be taken out of the room and you will hopefully and most likely also address the lack of understanding and get to the need of learning much easier.

An example of the process is below, this is from a real exercise.

The things that made it into the list

The things that didn’t make it into the list


The board of votes


Conclusion

Though probably not perfect, it is a way of getting the conversation going and making everyone aware of the fact that we have to be on the same page. You should never underestimate the importance of having the team thinking pretty much the same, and you need to address the core belief system in order for you to be close to getting your team thinking in the same terms. Having a team that anticipate each other and can have a dynamics together that pulls in the same direction gives higher velocity in the long term and also helps people keep motivated. Nothing is worse than not being motivated to go to work because of elephants and established truths. It can feel constraining and for someone not in the same mindset, completely arbitrary because the world has moved on ages ago.

Bottom line; communication is super important and probably the hardest thing to get right.


Tagged ,

Machine Specifications – .NET Core

I’ve been working on a particular project, mostly in the design phase – but leading up to implementation I quickly hit a snag; my favorite framework and tools for running my tests – or rather, specs, are not in the .NET Core space yet. After kicking and screaming for my self for the most part, I decided to do something about it and contribute something back after having been using the excellent Machine.Specifications Specification by Example framework and accompanying tools for years.

The codebase was not really able to directly build on top of .NET Core – and I started looking at forking it and just #ifdefing my way through the changes. This would be the normal way of contributing in the open source space. Unfortunately, it quickly got out of hand – there simply are too many differences in order for me to work fast enough and achieve my own goals right now. So, allthough not a decision I took lightly; I decided to just copy across into a completely new repository the things needed to be able to run it on .NET Core. It now lives here.

Since .NET Core is still in the flux, and after the announcement of DNX being killed off and replaced by a new .NET CLI tool called dotnet – I decided to for now just do the simplest thing possible and not implement a command or a test framework extension. This will likely change as the tools mature over time. Focused on my own feedback loop right now.

Anywho, the conclusion I’ve come to is that I will have my own test/spec project right now be regular console apps with a single line of code executing the all the specs in the assembly. This is far from ideal, but a starting point so I can carry on. The next logical step is to look at improving this experience with something that runs the specs affected by a change either in the unit under test or the spec itself. If you want a living example, please have a look here.

Basically – the needed bits are Nuget packages that you can find here, here and here.
The first package do include a reference to the others. But right now the tooling is too flaky to predict wether or not intellisense actually works using things like OmniSharp with VSCode or similar, so I have been explicitly taking all three dependencies.

The next thing you need is to have a Program with a Main method that actually runs it by calling the AssemblyRunner that I’ve put in for now.

Once you have this you can do a dotnet run and the output will be in the console.

.NET Core Version

Important thing to notice is that I’ve chosen to be right there on the bleeding edge of things, taking dependencies on packages and runtime versions from the MyGet feeds. The reason behind this is that some of the things that I’m using only exist in the latest bits. Scott Hanselman has a great writeup with regards to where we are today with .NET Core.


Future

Well, I’m not yet knee deep into this and not focusing my effort on this project. I’ll be building what I need, but of course – totally open to anyone wanting to contribute to this project. But if I were to say anything about my own vision and steps I can see right now that would be natural progressions for this it would be that I’d love to see the first step be an auto-watching CLI tool that will run the appropriate tests according to files being changed. I would not go all in and do a full analysis of call stacks and all to figure out what is changing, but rather have an approximation approach to it – similar to what we put in place for our test runner project for JavaScript called Forseti. The approximation was basically based on configurable conventions mapping a relationship between the systems under test and the tests – or specs as I prefer to refer to them as. After that I can see integration with VSCode – which is my favorite editor at the moment. Something similar to WallabyJS would be very cool.

Building a soldering station – step 1

When I first got started with IoT a couple of years back, I was fiddling at a very high level with the .NET Gadgeteer platform. Everything where finished modules with fixed wires with connectors on them that you just connected – voila; write some code and you had a fairly powerful device with a bunch of capabilities through the modules that exist for it. After going deeper in understanding and started working with the ESP8266 I got back into soldering again. Its been years since I’ve been there. As part of this, I went out and bought the things I didn’t already have; among this a pair of helping hands:


These just turned out to bee way too much of a hassle to use. Couldn’t really get a good stabile soldering station out of it and the helping hands ended up not being helpful at all.

I decided to research what was out there and couldn’t really find something that was affordable enough IMO. Being a hobby, I don’t want to flesh out too much cash on it.

After a bit of research I came across quite a few DIY projects and started planning out my own version, inspired by these. The ones I found the most interesting was the ones based on the gorillapod style camera tripod. The reason I found this the most interesting is that I wanted to have some really sturdy legs – and these are perfect IMO for the job. Anyways, the ones I got were these. With regular crocodile clips

The build

<>The first thing I did was to disassemble the tripod completely. You can simple pull the legs off by hand with a little force. I peeled off the base – it was glued to the end joint of the legs. With this, I ended up with the following


The next thing I did was to drill a hole in the end joint that is the end of the leg – mine was covered with rubber, so I took the rubber off, pulled the hemisphere off the leg and drilled a hole to fit the crocodile clips.


With the holes I could now start fitting the crocodile clips:

I decided to glue the clips to the hemispheres. This is a decision I might go back on and figure out a better way to attach them to the hemisphere. I’ve thus far had a couple of times they move out – not really a big problem, but still; perfectionism and all :).


The glue I used is a typical building bond:


My idea was to have a stone base – heavy enough to not move around when I am working. I had a particular look in mind and wanted to frame the stone. I decided to go with varnished oak, which gives a look I’m quite fond of.

On three of the sides I fitted the arms. I decided to go with stands from a prototyping board I had been using and put the arms on these. First I needed to drill holes for these and an inset for them to fit in.

This is how they fit in the inset.

On the flipside I just put a nut on it.

I then drilled a hole in the opposite hemisphere of the leg, the one that was glued to the base. This will then be mounted on top of the stand and attached with a screw going through.

With this in place you can attach a leg and get a general feel. On the picture you’ll see the stone I picked. It is in fact a regular cheramic tile with a specific stony look. This one I got for free at a local tile store. Turns out they hand out tiles for free for the purpose of sampling at home.

The last piece of the pusle is then to put together the frame and glue it all together. I decided on gluing it all with the same adhesive as mentioned earlier. Its not going to move around all that much, so my theory is that its more than good enough.

The end result



Next step

This is the first step of this – just to cover my most immediate needs; helping hands. I do however want to expand on it. For instance, adding compartments in front for all the consumables (soldering tin++), cleaning wool – but also a holder for the soldering pen that I use. I’ve also contemplated buying a more advanced soldering pen with a base for regulating the temperature and have looked at a couple that could easily fit in my build. Stay tuned – don’t know when though.. 🙂

My Internet of Things

Back in the days when I got started with computing as a kid, we soldered our commodore 64s quite a bit. We added things like reset buttons, which the computer didn’t have and similar. We modified like crazy, to make our every day of coding easier.

I left this itch behind for years until a couple of years ago when I started playing with the .NET Gadgeteer platform. Lowering the threshold to a bare minimum to get started. I ended up buying a lot of sensors and modules, but really didnt’t have a project to use all the stuff I had bought – until about a year ago. We had only ony remotecontrol for our garagedoor and I started looking at buying a second one. They were so expensive and I decided to build my own. It quickly exploded in what I wanted to do; it had to have RFID and eventually an app and much more, things like geo-fencing for automatic opening when I got close to home.

With high spirit I went all in and got it up and running on first attempt. There was a problem however, there were edge cases that caused the relay to generate an interrupt in the gadgeteer that looked like the button I had attached was clicked whenever the original remote was clicked. With next to no real understanding of how the electronics really worked, this completely stopped me in my tracks and I abandoned the project till I had figured out how to fix this. Then I discovered ESP8266 after an internal hackathon we had @ work. My mind was blown with the price. You could get for less than 2 USD, and it included a WIFI adapter onboard. My frame of reference being the Gadgeteer platform where you could easily end up paying 80 USD just for the WIFI adapter alone.

ESP

So, a computer – very small, with a 80/160 MHz CPU and a WIFI for under 2 USD. What could we do with this. Well, it does not provide the abstraction of the gadgeteer platform. But it is really not hard to dive in still. Sure, a few more things, different tools and a bit more hardcore – but very doable. Firstly, there are a few versions of the ESP. The simplest being the ESP-01 with only 2 GPIO ranging to the ESP-12 with 11 GPIO pins. Also in the mix are all the abstraction platforms often referred to as developer versions built on top of this to make it simpler to work with by exposing a USB header in front to be able to connect it directly to your computer. There is a good comparison of the most common ones here. I ended up researching this myself and ended up buying a lot of variations. My conclusion is that I will be running the ESP-07 for those scenarios when I want an external antenna for better reception and ESP-12 when I need more GPIO and ESP-01 for my basic projects.

Getting started

The easiest way to get started is to get one of these development boards. You should get a breadboard. But, I want to point out however – getting up and running without a development board is fairly easy. A bit more connecting things manually, but very rewarding when its done. Besides, tons of learning on the way – which I find the most important part of my journey. Anyways, to satisfy both cases there are kits out there that provide you with the breadboard, power supply for the board, USB to UART and the necessary wires. For instance this kit, which I bought. The USB/UART module here is based on the Prolific PL2303 and you need a driver for it, which can be found here.

If you’re going to be working a lot with the ESP-01, I recommend getting a breadboard adapter to easily connect and disconnect your ESPs. I bought this.

Moving beyond the breadboard when you’ve prototyped things, you can step up the game by going for the prototype PCB boards. Lowering the footprint and making it more permanent, but without having to play with chemicals or send your Fritzing drawing for production. I’ve personally not reached the Fritzing level yet – but aiming for it – so I’m happy playing with my soldering iron on the prototype boards for now.

Making things nice and feel more like proper devices instead of a spiderweb of wires coming out of your project, you can look at using connectors – you can get all kinds. I’m trying out different ones, for instance the 3 pin connector.

Power

One of my goals has been to create small self-contained devices, preferably with a certain WAF. This has meant that some sort of embedded power is important. This could be battery or its own AC/DC adapter making it possible to put it directly into a power socket for instance. All the components are easily accessible. For instance, there are some very neat and small AC/DC adapters for only 2-3 USD. If your project needs only 3.3 volts, you could go for this. If you need 5 volts, then this could fit the need. The ESP runs on 3.3 volts, so you would need to step down the 5 volts using a step-down converter like this. If you need more than 100mA for over time you need to look at other options. Remember however, working with AC is a lot more risky than the DC low voltage, low current things you end up with and you must be sure that the adapters are good quality so you don’t end up with a fire hazard. An option to this would be to just embed a USB charger, they tend to be small enough. Then at least you’re using something that is well tested and won’t invalidate your insurance.

What about those projects you want to place where there is no power source? There are quite a few options when it comes to batteries. You can use anything from a couple of AA batteries to a special purpose lithium polymer battery like this or if you need something like 6000 mAh you can go for something like this. There are chargers out there for these, but I’ve been looking at this and wanting to make it with an embedded charger and just expose an USB. Luckily there are solutions for that with something like this. These types of batteries is my goal in the long run, but for now I’m fiddling with regular AA batteries and also the 18650 batteries, packing a whopping 6800 mAh. Since they deliver 3.7 volts and have this capacity, I figured I could do with one battery for each project. So I went for this case holder. I also bought a charger for them. For holding your regular AA batteries, you can get something like this.

An interesting aspect when it comes to power is to make sure the device is not drawing more power than it needs to. Luckily the ESP has a few tricks up its sleeve that we can utilize to achieve this. Looking at Espressifs site, you’ll find the different consumptions you can go for.

20150112172151.jpg

For some purposes you might want to go all the way down to deep-sleep and just come out of it on a regular basis. If you’re measuring something on an interval for instance. The ESP-01 does not support the deep-sleep from a hardware perspective, but with some wizardry on the hardware you can get it to support it. Have a look at this. The beauty of this is that you can easily with the battery options I’ve mentioned get a solution that can last for years.

Development Environment

The default firmware will let you develop using C and you can lower the treshold using the Arduino IDE. Another option is to go for LUA, which the NodeMCU for instance comes with. To be honest it does not really matter which language you chose – as it will most likely be very small programs you’re writing anyways. That being said, I focused my effort pretty early on Espruino – it enables JavaScript. Sure, I’ve read the Pragmatic Programmer and should probably have chosen LUA, since I don’t know it – C is something I know very well, having written it professionally for 10 years. But couldn’t really see the huge benefit for me in this scenario, besides – LUA is not that different from JavaScript.

Flashing is pretty simple with the right tools. First you need to get the firmware from here. The flashing process is described here for all operating systems.

Once you’re up and running with flashing, you can use something like the Espruino Web Ide to do your development. It works fine and enables you even to connect to the ESP over WIFI. The ESP has a Telnet server, so once you’ve configured the network on the ESP you can simply telnet to it on port 23. Read more about configuring the network on your ESP and how this all works here.

My goal however is to be using Visual Studio Code for development and connecting to the board when I want to try things out. A promising project could then be this. I failed at getting it to work. I therefor started looking at alternative approaches to let me stay inside Visual Studio Code but just connect to the device and upload code easily. There is for instance the EspruinoTools that has a CLI tool. Unfortunately, this tool does not have the scenario of connecting over WIFI, which I found to be very good for me. So I ended up starting on a tool my self that can be found here. My first goal is to hook these up inside VSCode by using the task system. Who knows, maybe I’ll move beyond it – providing a more integrated experience.

Another thing that I find important for me is to be able to write nicer JavaScript. This is just an itch that I have, I could easily do all my work with the toolset I’ve described. I just have this “if I know I can do something better, I better do it”-itch. So ES2015 is a clear goal. This can be achived using things like BabelJS. I’m working on a set of Gulp tasks to do this. Sure, there is a slight overhead with this on the memory footprint. But with bundling and minification in combination, I should be able to aleviate some of this. Besides, I think memory is not going to be an issue for most of my projects. Well, at least not until I start pulling in MQTT libraries or similar. 🙂

Summary

The treshold for building IoT stuff today has really been lowered. Sure, we can still do things like the gageteer things or maybe even better yet for kids do something like LittleBits. Once you get the hang of things and have an urge for diving deeper, it still is not all that hard. I’m impressed with the amount of resources out there, so learning should really just be a question of crawling the web – and it shouldn’t be hard. The hardest part I found was getting the vocabulary right. What are the names of all the things I needed for my projects. This is still a pain point, but I’m not sweating it too much – I see that it increases day by day. I’m totally hooked and really have found a hobby that is a lot of fun where I can also build things that are somewhat useful at the same time.

One thing I find really interesting is the evolution of the ESP platform, it has exploded in just a couple of years – and its still being pushed forward. The upcoming member to the family; ESP32 is very interesting with its bluetooth option and more GPIO. Really looking forward to it coming out.

Hope you found this writeup useful – feel free to add pointers and correct me if I’m wrong on things in the writeup (I’m pretty sure I’ve misunderstood a few things in my journey thus far).

Bifrost – end of the line

Prior to 2008 I had only worked at ISVs (Independent Software Vendors) and game companies going back to 1994. At this point I decided I needed to get a change of scenery and become a consultant – try something completely different. In the beginning, since I had no experience with being a consultant – my boss and me figured it would be best to have a few small projects to get the gist of things. After a couple of these small projects I started feeling some pain; I was rince-repeating a lot of the things. I’m not entirely sure how other consultants do things, but I decided it was time to gather the things that I was constantly doing into an open-source library; a collection of tools that would speed up the process when onboarding into projects. From this Bifrost was born.

It grew from over a couple of years and at the time had no true vision other than make my everyday easier. Back in 2009 I got hired as a consultant @ the largest eCommerce in Norway; Komplett. At Komplett I was tasked at first with working on some integration and establishing a new object model, or as we liked to call it back then; a domain model. It was pretty much an anemic domain model, something representing the data in C#. An approach I had done a number of times over the course of my career at this point. In the middle of this work, someone had discovered a missing feature in the system which was a critical feature for a company being merged into the Komplett group. I was asked to head development of this feature and I could bring 2 more devs. We decided to make this a learning experience in addition to concretely implement the feature. In the learning we wanted to pick up on new ways of thinking and also some new tech, amongst it ASP.NET MVC. The team ended up being Michael Smith, Pavneet Singh Saund and myself, plus a dedicated product owner. We did quite a few discoveries in this project and by far the most important being the discovery of commands. We also discovered how domain models as we knew at this point in time didn’t really work. Worth mentioning is also how we started seeing patterns of how we should not do things. This lead to larger project, a rewrite of the core web. Midway through this, I gave a talk @ NDC 2011 about our experience with applying CQRS, which was the conclusion we were closing in on. From this I was contacted by a representative of Statoil a few months later. They found the topic interesting and also the platform; Bifrost (yes we got pretentious and dropped the library and framework label and called it a platform – it kinda grew 🙂 ). We were onboarded in the beginning of 2012, and I mean we – Michael joined and later also Pavneet. Kept the team together, all as individual independent consultants. This was a huge part of our progress in learning; the team. We knew each other well, had concrete focus areas and managed to move and learn fast.

At this stage we found ourselves in a position of having gone through a sort of knowledge transition. To me it felt like I had gone back quite a few years from 2008 and created a fork in my knowledge bank. It felt at times like this fork was diverging more and more from what was commonly being done on projects around us. Not claiming that our fork was better or anything, but made more sense to us – with our history together and our shift in mindset that we decided to do. From my experience, comparing before and after – I conclude with we managed to write better and more predictable software. But it came with a certain amount of friction. The stuff we were talking about was not as Google-friendly. Less resources to refer to, which is a very important aspect when you have for instance a team of 20+ developers that you’re trying to convince that your thing is better; not to be underestimated at all! Something we were quite aware of and made us a bit hesitant to push through, but had confidence from key persons on the projects we were on to push forward. The huge disadvantage I’m seeing today of having pushed on in this fork and having to spend a lot of time maintaining and convincing others, left us blind to what was going on outside and we became an echo-chamber for a lot of things, not realizing that some of the concepts we had discovered and if I dare; maybe even pioneered (without letting anyone know) has surfaced in elsewhere and are now becoming part of how we all do things. Which is just truly great.

 

The future

 

Its now been 7-8 years since the project was started, where is it today. Well, it still exists, sits on GitHub. Thus far the project has moved forward because of the maintainers needing it to. We were using it for the projects we were on. This has also been the key reason why we’ve implemented things; if it had a real world scenario – we could identify it and develop it. We’ve always kept a close eye on the real world, not making anything for its own purpose – but fill a need. Fast forwarding to today, February 2016, our team is no longer a team and skattered in different companies. We are no longer working together, and none of us really using Bifrost for our day to day work – this represents a problem for moving things forward, given the history of how things have moved. Take me for instance, I’m no longer actively working on a real world project – although I’m working on changing that somewhat. To keep my knowledge fresh in the type of role I have now, I’m dedicating time to build a project I’ve been thinking of for a couple of years and something I need myself. But it turns out, this is not enough of a reason for me. I have decided to go a slightly different route to build relevant knowledge to what I do.

One of the goals of Bifrost was to tackle things we believed would provide better quality software, one of them being to decouple and not build monoliths. Today, I see Bifrost as a bit of a monolith. There are too many things inside the core framework. It should have been broken up. On top of this there also are some logical couplings we never intended. There are also things I’d like to do differently in how its been architected, and basically learn from mistakes and correct them. Worth mentioning is also complexity that was put in there for imaginary problems that turned out to not be anything that would happen any time soon. For those using Bifrost, it would be too much work moving forward with the amount of refactoring that I’m looking for, plus too much work for me or anyone else maintaining it all. Although difficult, I see no other way around it but to just admit that I will not be able to set aside time to do this properly and therefor I will not continue the maintenance of it, nor maintain any pull requests at this point. When I can’t guarantee a feedback loop, it only looks bad in the repository. I’m truly proud of what we have accomplished with the project. It is by far the cleanest code I’ve ever written, adhering to the principles that I believe in. With more than 2000 automated specifications (BDD style), it has proven to be easy to refactor and as far as we know; very stable code – thoroughly tested. There are of course things I’d love to have done differently. Blogging more actively about the things we did in Bifrost, creating awareness – because as I said, I’m truly proud of what we have done. Actively maintaining documentation is a second thing – making it easier to figure out what things do. We did put in XML documentation into all C# code, but never really did anything proper with it. I’d also do WebCasts to cover topics, create tutorials and more. Who knows, maybe Bifrost could have been a business on its own. The luxury of looking back :).

 

Harvesting

The last couple of months has been a retrospective going on inside my head with the purpose of figuring out what I think was good and not. In combination with this, Pavneet, Michael and myself has had a few discussions between ourselves about the same topic. Gaining the distance from everyday maintenance and implementation has really helped and has made things a lot clearer.

From this I want to start harvesting from the experience. Primarily I want to harvest in the term of learning, take the knowledge and bring it forward – modernize it – keep it fresh. Then I have a hope, not willing to call it a goal yet, to turn this knowledge into something more concrete. I’m not entirely sure what this concrete thing is yet. If it appears in the wild in terms of an open-source project representing this or not, I’m not sure. I’d love to, but only if I find it viable.

What I do concretely want to do is to start braindumping some of the things we learned, the things we really enjoyed and we found useful. The braindumping will be in the form of posts here.

Below is a list of topics from the top of my head that I see as key points for the kind of harvesting I’m talking about. I have no idea what format things will take and what will end up where, so lets see.

 

  1. Core Principles – SOLID, SOC, DRY
  2. Productivity and true meaning
  3. Discovery mechanisms and Conventions
  4. Cross cutting concerns
  5. Domain Models
  6. Commands
  7. Events + EventSourcing
  8. Domain Driven Design
  9. Eventual Consistency
  10. Low Coupling, High Cohesion
  11. The importance of the clientside
  12. Validation != Business rules
  13. Operations
  14. MVVM – the building blocks
  15. Regions in the client
  16. Coding style
  17. BDD – Specifications by example style of testing
  18. Feedback loop
  19. Declarative
  20. Compositional software
  21. How inheritance creates coupled software
  22. Don’t be afraid of duplication in data – persistence polyglotism
  23. Bounded Contexts and their relationship to MicroServices

 

 

Conclusion

Being realistic can sometimes be hard. I must admit I have not been honest with myself nor with others. Its hard when its your own brainchild to let go, but the place I am in my life right now has little room for maintaining a project the size of Bifrost. I have a job that is different and demanding in its own way, I have 2 kids thats growing up and I must prioritize being there more for them before its too late! I have neglegted hobbies that I’m trying to get in touch with; my IOT devices, writing more blogposts, attending user groups. I have a house that I want to do some work on and tons of tools to do it with that’s screaming for my attention. I’m also active in the school, in something similar to PTA here in Norway. The only correct and honest thing to do is to tell everyone; I’m not going to maintain Bifrost anymore – nor maintain pull requests. Thanks to everyone that believed in the project, the guys maintaining it and fellow journeymen; Michael, Pavneet. A big shoutout and thanks to Børge Nordli who is on a project using Bifrost and has the last year contributed quite a bit back.

PS: Project will still sit on GitHub

 

6 months into it

Time flies when you have fun, they say. Its been 6 months into my life @ Microsoft. Figured I’d summarize a bit.

The first indication I’ve been busy is the fact its actually also been more than 6 months since I posted anything here. That is just crazy. I know I kinda have slowed down the last couple of years, but never to this level of NADA, ZIP, ZERO.. And trust me, its been very busy.

Onboarding @ Microsoft has been a lot of fun – so much to learn, and I love learning! My role; Technical Evangelist – really does not explain what I do – at all. Basically I’m more of an advisor. My job is to help ISVs in Norway get the best experience in Azure. The thing is; there are an estimated 600+ ISVs in Norway. Some of these aren’t ones we would talk to, based on “natural selection” (basically, those not doing anything or have any plans of doing anything in any cloud). But even after this, there are enough left to talk to at least one ISV every day. I work in a team with 3 others representing more of the business aspect of working with the ISVs, with different focus areas ranging from startups to more established ISVs. Needless to say, these guys run in a lot of meetings, talking and trying to figure out what ISVs are interested and need to dig deeper. This is were I enter; try to understand their business and what technical needs they have – but also what needs they might have based on where they see their business go. On occassion I dive deep and get involved in creating proof of concepts that requires me to deliver code – not something that will be put in production though.

One of the true joys of the prototype part is that I can do things in the open @ GitHub when I identify common things that would benefit more than one partner. Having done open-source development for a few years, I’m careful though. Anything put out there needs more attention if its a reusable component.

Then there is this fact that my role is called Technical Evangelist; there is a part of the job that actually involves doing presentations and write blogposts. And I love both.


Different

I’ve worked a few places in my career. But hands down, Microsoft is different in all aspects – in a good IMO. Fair enough, I don’t have the type of role I’m used to having – but that aside, there is something to be said for the working environment, focus, structure and pace.


EMail

So.. What are these team chats you talk about. After getting used to everything being available on Flowdock or Slack for a couple of years, email feels like a true step down. This is a massive difference. The amount of emails I receive is ridiculous – but its needed. And I am coming to the realization that none of the tools I’ve been using could fix this in any way. So even with its shortcomings, email is king and I’m learning to live with it again. Its probably been 10 years since I’ve had to use folders to organize my emails – now after only 6 months I must have a 100 or more folders.


How about that coolaid?

Well.. Before I started @ Microsoft I had a few things I was starting to dislike about what they were doing. I felt that there was a need for revitalizing some of the tech and to be honest – recognize that there are other platforms and really start targetting them. I’m a Mac guy – and have been so since 2008. At this point in time I made a decision to step outside the Microsoft bubble I was in. It lead to a lot of cool new experiences and my favorite part; learning. Most of this learning I brought back to the projects I was on, which was C#/.NET projects. But the change of platform meant I had to actually learn new things which again lead to me wanting to explore even more. I grew back my apetite for learning. My wish has come through; Microsoft over the last couple of years have done the exact same thing and exactly what I criticized them for not doing when I was on the outside. The amount of stuff that has been open sourced for instance. Most of the things being done has a cross-platform thinking going into it. I’m really loving this. And yes, I’m half way down the cool aid. Azure has been on my radar and in my toolbox ever since it was launched in 2008 @ PDC. With all the new stuff thats going on top of this, I am truly smiling. I can now do all the things I’ve grown fond of over the years and the best part; I can use the best tool for the job – mix and match – on almost any platform.

My Biggest Challenge

Having a role like I have requires me to pay attention to a lot of things. Being in a small country, we don’t have the luxury of having a lot of people focusing on the different aspects of Azure – I basically have to know most of it, or at least know of it and go deep when called for. This is kinda fine, its knowing technology – and over the years one kinda absorbs new technology without too much hassle. The biggest challenge to me is to not stay in touch with real projects and gain real true experience with actually deploying the technology. This is truly the most important aspect in my opinion. Its when you use things you learn what works and what doesn’t. We’ve put in motion actions to actually gain the needed experience across our department. But in addition, I’m now starting a pet project that I’ve been planning for a couple of years and as luck would have it; the project will touch on most aspects of Azure. Now that I’ve gotten past the initial hurdles and starting to get a bit more comfortable with my role, I think I’ll be able to have the extra energy at night to do this.

Conclusion

In conclusion there is no conclusion. This is all so new and different that I just have to go day by day and see what is behind every corner. I’m excited, willing to learn and highly motivated. These things help.. 🙂




New and interesting challenges

First of July I’m starting @ Microsoft Norway in the Developer Experience (DX) team. My official, on the paper, title is Technical Evangelist – which might sound scary enough. But in reality it’s a multifaceted position ranging from sure enough evangelism in the sense of talking about Microsoft products and promotoing these, to advisory for clients, community work, blogging and more. My particular role will be geared towards the cloud; Azure, but I will be sure to keep in touch with the entire stack – as I really love keep on top of things. I spend a lot of time in front of the computer both work and non-work related, so I’ll be sure to keep up.

I’ve worked closely with Microsoft since 2001, since 2008 I’ve been a Microsoft MVP and at times its felt like I’ve been an employee without having the privileges an employee has. So when my new boss said to me a couple of weeks ago; “Welcome home..” – that is the feeling I actually do have.

The timing for me is perfect, both on a personal level, professional level and seeing all the cool things that really excites me that is going on at Microsoft these days. I’m bursting with joy for how Microsoft has turned around and really looking forward to engage more in the coming years with this.

How does this impact other things. Well, I’ve had a company on and off since 1997 called Dolittle. At first as a way of picking up freelance work and the last few years more focused. I am closing down the company. Keeping the brand though, with domains and all, but putting it to sleep as a company. For other things, the opensource projects I’m involved in; Balder, Bifrost, Forseti and more. I’ll keep on working on them when I have a chance. Maybe not as focused as before, as I’ve had the pleasure and luxury of being able to maintain the projects at work for the last few years. They’ve been with me for years and are babies to me, so it would be hard to let them go. Besides, they serve a great purpose for me in keeping up with the whats going on the world of development. I am a developer after all and if I am to do a good job talking about it, I need to maintain my knowledge.

I’m super excited and honored to become a member of the team. Really looking forward to it.

SignalR: Blueprints

When I wrote my first book; SignalR: Real-time Application Development, I was not entirely sure I’d ever write another anytime soon. First time author and a bunch of rookie mistakes during the initial draft of the book costed me a lot of blood and sweat getting to the second draft and then eventually the release. Even though not a big book, I was exhausted trying to juggle the writing and doing my day job. But got back on the bandwagon and eventually started on my second book, this time around actually learning from the mistakes and the whole process was so much smoother.

The end product; SignalR Blueprints. 

 

You can get it as print or eBook from Packt or Amazon.


The elevator pitch

SignalR is a piece of tech that opens up great opportunities for your apps. It enables a client connected to your server to be persistently connected allowing the server to push messages to any connected client. This opens up a pathway for new ways of doing things, making our software better in technological terms but also from a user experience perspective, which is the biggest reason one should pick up on this. SignalR Blueprints takes you on a journey presenting the usage of the technology paired with different environments ranging from ASP.NET MVC to CQRS based onto mobile devices such as Windows Phone, iOS and Android using Xamarin with a high focus on code quality all the way through but more importantly a high focus on the user.


Thanks are in order…

I’d like to thank the entire editorial staff at Packt for pointing me the right direction and making it a smooth process. High five and great thanks to Sumeet Sawant and Shashank Desai for their excellent work as respectively Content Development Editor and Technical Editor, you and your teams have really helped raise the quality of the product. A big thanks to the technical reviewers as well; Dejan Caric, Anup Hariharan Nair and Michael Smith.

Concepts and more

With Bifrost we’re aligning ourselves more and more with being a platform for doing Domain Driven Design. Introducing more and more artefacts from the building blocks as we go along. When we set out to build Bifrost, we decided early on to be true to not be building anything into it that we didn’t need in a real world scenario. This was after we had started falling into the pattern of what if of software development. We started imagining problems and had to deal with them way before they had actually happened. With the risk of generalising; a fairly common scenario amongst dirty minded tech people. It stems from experience, knowing that there will always be something that can go wrong. Sure, there always is. I digress, I think this could probably be a blogpost on its own. The point being, we were heading down this path and for some reason got jolted back to reality and we started focusing on implementing only the things we needed and rather actually go back and remove things that came out of the “what if game”. On this new path we wanted to also stay focused on implementing things that were aligned with DDD and keep a close eye on the user.

Concepts

With the philosophy of CQRS at heart built with SOLID care we keep a very close eye on being very specific in our modelling. Things that are used in one part of the system is not automatically reused somewhere else, for the DRYness. We don’t believe in DRYing up properties and we favor composition of inheritance. Logic is still kept only once, on the command side of the fence. With all these principles at hand we were missing something that would link it all back together and make things look and feel consistent.

Let’s look at a scenario; say I want to update the address of a person. A command could be something like the following:

using System;
using Bifrost.Commands;

public class UpdateAddressForPerson : Command
{
   public Guid PersonId { get; set; }
   public string Street { get; set; }
   public string City { get; set; }
   public string PostalCode { get; set; }
   public string Country { get; set; }
}

In Bifrost you’d then have a CommandHandler to deal with this and then an AggregateRoot that would probably look like the following:

using System;
using Bifrost.Domain;

public class Person : AggregateRoot
{
   public Person(Guid personId) : base(personId) {}
   public UpdateAddress(string street, string city, string postalCode, string country)
   {
      // Apply an event
   }
}

The aggregate would then apply an event that looks like the following:

using System;
using Bifrost.Events;

public class AddressUpdatedForPerson : Event
{
   public Guid PersonId { get; set; }
   public string Street { get; set; }
   public string City { get; set; }
   public string PostalCode { get; set; }
   public string Country { get; set; }
}

An event subscriber would pick this up and update a read model that might look like the following:

using System;
using Bifrost.Read;

public class AddressForPerson : IReadModel
{
   public Guid PersonId { get; set; }
   public string Street { get; set; }
   public string City { get; set; }
   public string PostalCode { get; set; }
   public string Country { get; set; }
}

That was the artefacts we would typically be dealing with; command, aggregateroot, event and readmodel. For simplicity, these look pretty much the same – but they don’t have to, and in fact; most of the time they don’t. Lets address something here. We’re losing out on a potential in the modelling here. Take the Guid representing the unique identifier for the person. This is in fact something  that is part of the domain vocabulary that we’re losing by just making it a Guid directly.

In Bifrost we have something called ConceptAs that we can use to represent this domain concept. This is a base class that we recognize throughout the system and deals with properly during serialisation between the different out of process places it might go.

using System;
using Bifrost.Concepts;

public class Person : ConceptAs<Guid>
{
   public static implicit operator Person(Guid personId)
   {
      return new Person() { Value = personId };
   }
}

What this does is to wrap up the primitive, giving us a type that represent the domain concept. One modelling technique we applied when doing this is to stop referring to it as an id, so we started calling it the noun in which it represented. For us, this actually became the abstract noun. It doesn’t hold any properties for what it represents, only the notion of it. But codewise, this looks very good and readable.

In the ConceptAs base class we have an implicit operator that is capable of converting from the new type to the primitive, unfortunately C# does not allow for the same implicit operator going the other way in the base class, so this has to be explicitly implemented. With these operators we can move back and forth between the primitive and the concept. This comes very handy when dealing with events. We decided to drop the concepts in the events. The reason for this is that versioning becomes very hard when changing a concept, something you could decide to do. It could also make serialization more complex than you’d hope for with some serializers. Our conclusion is that we keep the events very simple and uses primitives, but everywhere else the concept is used.

The way we structure our source we basically have a domain project with our commands, command handlers and aggregates. Then we have a project for our read side and in between these two projects sit a project for holding the domain events. With this model we don’t get a coupling between the domain and the read, which is one of our primary objectives. The concepts on the other hand, they are going to be reused between the two. We therefor always have a concepts project where we keep our concepts.

Our typical project structure:

2015-02-03_07-43-27.png

So, now that we have our first concept, what did it do? It replaced the Guid reference throughout, introducing some clarity in our models. But the benefit we stumbled upon with this; we now have something to do cross cutting concerns with. By having the type of pipelines we have in Bifrost, we can now start doing things based on the type being used in different artefacts. Take the command for instance, we can now introduce input validation or business rules for it that would be applied automatically whenever used. Our support for FluentValidation has a BusinessValidator type that can be used for this:

using Bifrost.FluentValidation;
using FluentValidation;

public class PersonBusinessValidator : BusinessValidator<Person>
{
   public PersonBusinessValidator()
   {
      RuleFor(p => p.Value)
         .Must(… a method/lambda for checking if a person exist …)
         .WithMessage(“The person does not exist”);
   }
}

As long as you don’t create a specific business validator for the command, this would be automatically picked up. But if you were to create a specific validator for the command you could point it to this validator as a rule for the person property.

The exact same thing can then also be used for an input validator, which then would generate the proper metadata for the client and execute the validator on the client before the server.

It opens up for other cross cutting concerns as well, security for instance.

Value Objects

A second type of object, with the same importance in expressing the domain and opening for solving things in a cross cutting manner are value objects. This is a type of object that actually holds information, attributes that have value. They are useless on their own, but often used in the domain and also on the read side. Their uniqueness is based on all the fields in it. We find these in any domain all the time, they are typical things like money, phone number or in our case address. These are just the off the top of my head type of value objects you’d have, but you’ll find these in many forms. Lets tackle address:

using System;
using Bifrost.Concepts;

public class Address : Value
{
   public string Street { get; set; }
   public string City { get; set; }
   public string Postal { get; set; }
   public string Country { get; set; }
}

 

The Value baseclass implements IEquatable and deals with the property comparisons for uniquness.

With the value object you do get the same opportunities as with the concept for input and business validation, and yet another opportunity for dealing with cross cutting concerns.

If we summarize the sample before with these new building blocks, we would get:

using System;
using Bifrost.Commands;

public class UpdateAddressForPerson : Command
{
   public Person Person { get; set; }
   public Address Address { get; set; }
}

Our event:

using System;
using Bifrost.Events;

public class AddressUpdatedForPerson : Event
{
   public Guid PersonId { get; set; }
   public string Street { get; set; }
   public string City { get; set; }
   public string PostalCode { get; set; }
   public string Country { get; set; }
}

As you can see, we keep it as it was, with the properties all in the event.

Our AggregateRoot:

using System;
using Bifrost.Domain;

public class Person : AggregateRoot
{
   public Person(Guid person) : base(person) {}

   public UpdateAddress(Address address)
   {
      Apply(new AddressUpdatedForPerson {
         Person = Id,
         Street = address.Street,
         City = address.City,
         Postal = address.Postal,
         Country = address.Country
      });
   }
}

The readmodel then would be:

using System;
using Bifrost.Read;

public class AddressForPerson : IReadModel
{
   public Person Person { get; set; }
   public Address Address { get; set; }
}

Conclusion

For someone more familiar with traditional N-tier architecture and modelling your EDM or rather than separating things out like this, this probably raises a few eyebrows and questions. I can totally relate to it, before starting the Bifrost journey – I would have completely done the same thing. It seems like a lot of artefacts hanging around here, but every one of these serves a specific purpose and is really focused. Our experience with this is that we model things more explicitly, we reflect what we want in our model much better. Besides, you stop having things in your domain that can be ambiguous, which is the primary objective of DDD. DDD is all about the modelling and how we reach a ubiquitous language, a language that represent the domain, a language we all speak. From this perspective we’ve found domain concepts and value objects to go along with it to be very useful. With them in place as types, we found it very easy to go and retrofit cross cutting concerns we wanted in our solution without having to change any business logic. When you look at whats involved in doing it, its just worth it. The few lines of code representing it will pay back in ten folds of clarity and opportunities.

Life vNext

Tomorrow, 5th of January 2015, I’m starting a new job – not for a client, but an actual new job. The place is called dRofus. I’m very excited about starting. It marks the end of my now soon 7 year career as a consultant and means I’m moving back to product development, which has been what I’ve done for the most of my career from 1994 till 2008. This gets me truly excited. I’m so much more a product developer than a consultant. I quite enjoy maintaining things over a long period. Don’t get me wrong, I love doing new things, but the idea of improving something over time is something I love. 

 

Back in 1997 I started a company called Dolittle – basically as a freelance thing, something I did on my sparetime, developing products for different companies. Meanwhile working for different companies at day time, I kept this company dormant and activated it when I got opportunities I felt I had the time to do. In 2010 I took the final step; I swapped out my daytime job with the sparetime and really took the plunge and got long term contracts with clients leading me all the way to today. During this, Dolittle became 3 guys. The three of us hit it off on a project and decided to see what we could do together.

 

2014 has been a very hectic year, its the year I didn’t really have time to blog – even though it marked the 10th anniversary since I started my blog. The first half of 2014 was pretty much dedicated to getting a product for a client out the door and on its way to the users. Seeing that the contract for the 3 of us was coming to an end, we started looking around for new things to do. Our goal was a long term project that the 3 of us could be on together. While looking, I got a 6 month extension to the contract and we got a request for one of the others for a long term contract. On top of this we had a project we were all doing bits and pieces on for a client every so often. We had enough work, but still wanted to get the three of us onto the same project. At NDC in June we all went to try to create a bit of a buzz, got a few leads from it; but nothing concrete. The summer went and we started broadening our search, creating more material to show what we had done and what we represented. Still, projects we came over were for one person. In fact, the third of us picked up one of these ensuring. During our expansion, we started looking outside our geographical area; Vestfold – Norway. We knew that it was a tough market in that area, but we wanted to try it out first before expanding. The minute we expanded after the summer, it started picking up. After a few meetings we got great feedback from a few clients impressed with what we had achieved. During this, we were headhunted individually by different companies looking for resources. This completely threw us off. We knew we weren’t really the perfect fit for being consultants, as our focus has always been on the product in a longer perspective than consultants normally get to do. All of a sudden we found ourselves doing interviews and at a couple of places we were doing interviews all together, as they wanted the entire crew. Long story short, we got opportunities we could not say no to. Two of us (myself and Michael Smith) ended up accepting an offer from dRofus. Our third chap; Pavneet Singh Saund accepted an offer at a more local client, which makes totally sense for his situation. 

 

What about Dolittle?  Well, it will have to back into a dorment state. I’m not a person to give up, and I don’t see this move as giving up. It was just not meant to be right now. But who knows, that could change in the future. However, I hope if it changes that it changes to be a product and not back to being consultants. 

2015

In many ways, I think for my own sake that moving into a regular job right now is a really good move. I get to focus more on my kids than I have had for the last couple of years. I also get to focus more on other things I love, such as blogging, local dev-community work, writing books and more. I will also try to be more visible on stage and talk about topics I feel passionate about.

Bifrost and other projects

So, what happens with the open-source projects I’m involved in. Well, having clients that push the development forward has been a luxury for the projects we maintain. It really has had an excellent velocity due to this. That being said, I’ve already mentioned for my new employer that I’m part of a couple of projects and that I would be surprised if they wouldn’t fit in their products as well. My employer has said we will need to look into it in more depth. But it is most likely the most perfect timing to introduce Bifrost as they are looking at rewriting a lot of the product.

 

However, I am expecting to have a lot more time on my hand to maintain these projects now. They are projects that has been with me for quite some years now and I’m not about to give up on them. We’ve been very clear that we were never going to develop on the projects without a real business need and these would come from real projects. We do however know a lot more now than when we started and I’m expecting to go back and refactor things, make a few things more focused and also modernize a few things as well. In addition, there are needs we know about that we found on real projects that we have yet to implement – so these will be put in as well. But the overall vision will be maintained; don’t make things in the projects without a really well founded argument. 

 

 

Wish me luck..