DEV Community: Sarah Williams

Fight for the Architecture

Sarah Williams — Mon, 19 Feb 2018 17:39:13 +0000

I’m currently reading Clean Architecture by Uncle Bob. I’m still pretty early on in the book, but I just read a section that made me need to put it down and write this post!

Developers are stakeholders too

In a section titled ‘Fight For The Architecture’, Bob talks about the ongoing struggle of fighting for what you as a developer and/or architect believe is right for the company. Just as the management team, marketing team etc also do. The part of this section that really stood out to me was this:

[Effective software development teams] unabashedly squabble with all the other stakeholders as equals. Remember, as a software developer, you are a stakeholder. You have a stake in the software that you need to safeguard. That’s part of your role, and part of your duty. And it’s a big part of why you were hired.

This, so much this! I think this is something you don’t tend to recognise early in your career, at least I know I didn’t. I also think that if the company doesn’t recognise their development team as a stakeholder, it’s a steady slope to a product that will eventually fail. Without time spent on the architecture, you’ll end up with a product that’s more and more difficult to add to and maintain. You’ll have to add more people to the team, but your output won’t increase because the code base is harder to work in every day. Every line of code gradually gets more expensive to write, but your output will no longer match your investment. Eventually it’s going to need to be rewritten or abandoned.

So for the developers reading this, remember, a software development team is definitely a stakeholder in the product they are developing. Sometimes we have to stand up for something for the good of the product and help make the other stakeholders understand why it’s important. We are in these positions because we understand the technical implications and because we’re good at what we do. If you sit back and let things go, you’re going to end up working in a mess of code that’s definitely not fun to work on and is challenging for all the wrong reasons!

^{Cover photo by sydney Rae on Unsplash}

This was originally posted on my blog in January 2018

Why Fusion Drives & Windows Don't Mix

Sarah Williams — Wed, 26 Jul 2017 08:56:19 +0000

My machine at work is a late 2015 model iMac, bought in August 2016. It's got a decent spec. The main bits, 3.3GHz i7 processor, 16GB RAM and 1TB Fusion Drive. That should definitely cover my requirements for development work, shouldn't it?

I spend 99.9% of my time in Windows. Due to my machine having 16GB RAM (which is what I want Windows to have to help out with memory hungry apps like Chrome, Slack and Visual Studio), it's an easy decision to install Windows in a Bootcamp partition rather than on a VM where I would have to share resources with OSX.

Fairly quickly after getting my iMac set up, I noticed that it was a bit slow in Windows. For quite a while I just put this down to me being spoiled by the SSD in my Macbook Pro that I use at home. As the months have gone on and the requirements for my work have gotten more intense, it's started to get to the point where I often find it unusable. I tend not to shut my machine down, instead just putting it to sleep. After a week of this, it takes around 25 minutes to close everything, reboot and open everything back up again. Even it it's only been on for one day, it can still take 12 to 20 minutes.

I booted into OSX recently for the first time in around 11 months and noticed it was running much quicker, close to the performance of OSX on my own Macbook Pro. I decided it was time to research and finally I found the reason why I regularly want to throw my machine out of the window I sit next to.

When you install Windows on a Bootcamp partition on a Fusion Drive, Boot Camp Assistant creates the Windows partition on the disk drive, not the SSD.

And here it is straight from Apple - https://support.apple.com/en-gb/HT201456 - see the 8th FAQ down (at the time of writing).

In a way, I'm happy because I at least know that it's not just me being impatient! I'm also a bit annoyed with myself though. Firstly for not doing any research into how exactly a Fusion Drive works before we went into the Apple Store to buy the machine, and also for not just registering that the Fusion Drive is an Apple concept so probably doesn't work elsewhere.

So hopefully someone finds this because they're doing what I should have done, research!

My personal opinion, if you're thinking of installing Windows in a Bootcamp partition on a Fusion Drive for full time dev work (or anything moderately intensive), don't do it. Go for the SSD. It runs like a dream on my Macbook Pro! Alternatively, if you really want to/don't have a choice and go for the Fusion Drive, the new model 21" iMac (and the 27" iMac) can have up to 32GB RAM now. I have tried Windows in a Parallels VM on the Fusion Drive and it does run better than it does in Bootcamp. So if you do go for a Fusion Drive, also go for 32GB of RAM and run Windows in a VM rather that on a Bootcamp partition.

This was originally posted on my blog in June 2017

Are You Feeling Lucky?

Sarah Williams — Wed, 05 Jul 2017 13:25:03 +0000

The past few days I've been struck with this lucky feeling.

As I scroll through my Twitter feed, I realise I'm following some amazing people who are brilliant at tech. And thanks to Twitter, I have access to all these great minds in one place! As they share their insights and links to articles, I get to read it all and learn from it.

Over on Slack, some local developers had the great idea to set up a group for local tech people to join. The early days in a startup can be difficult because the team is small, sometimes you need someone else in a similar position to yourself to bounce ideas off. Today I wanted someone to look at my plan for how I'm intending to structure our live Azure environment to make sure I wasn't doing anything crazy. A quick plea in the local tech Slack channel and less than an hour later, a complete stranger had offered their help and then spent almost an hour talking to me.

In all of these cases, the people are the most important part because without them the tools wouldn't be of as much use. However having access to these tools makes these connections infinitely easier.

Developers often joke that they couldn't do their job without Google, but I think that list is definitely starting to grow.

What tools do you use on a daily basis that you wouldn't want to be without? Do they make your job easier or more enjoyable? Do they make you better at what you do? Are there any particular people you follow that you find inspirational?

All of the Problems! How I Stay Sane

Sarah Williams — Fri, 30 Jun 2017 12:55:39 +0000

Most of my job as an architect in the early days of a start up lives in the realm of disorder. We're in the process of really getting to the heart of the problem that we're working to solve and as we define that, I need to analyse the options of how we can technically create these solutions. As I work the problem, the picture becomes clearer and gradually I get to the point where I have a solid plan and code is being written to implement it. Sometimes other problems get thrown up along the way and I need to figure out where they sit on the scale of "WTF?!" to "oh yeah no problem".

A few years ago I was shown the Cynefin Framework. The Cynefin Framework was developed in the early 2000's at IBM as a sense making device. As a side note, it's nice to see a Welsh language word in tech language (cynefin is Welsh for habitat). For the non-Welsh speakers out there, it's pronounced kun-ev-in. Anyway, I probably picture this diagram in my head on a daily basis at the moment. Whenever I'm considering a problem or when a new problem gets raised, I think about where it sits on this diagram.

Link to original file

My thought process tends to go clockwise, starting at chaotic. The first step is, we have a problem. We discuss it, make sense of it, define it and eventually begin to come up with an idea of how we think we could solve it with the software we're building.

I then enter the complex domain. I have an idea of an end solution to the problem. I have to think about how we can technically solve that problem in the larger context of our entire system. This domain for me will usually involve some proof of concept work and eventually I'll come up with a plan for a technical implementation to help us get to our end solution.

The next domain is complicated. For me, this is where I actually start putting some high level work into our architecture, making sense of how this implementation actually fits in. I see this step as the part where it goes from being and idea in my head or on paper, to being an implementation. This part can be slow and a bit frustrating for me personally, but when the solution is taking shape, it becomes a very rewarding part of the process!

Eventually you get to the simple domain. The architecture is now in place so here we're fleshing out the details and putting all the implementations in place using well known solutions and techniques that I've used lots of times before.

Problems don't always need to start in the chaotic domain.

A problem can start in any domain. Sometimes a problem will come up that will go straight into the simple domain, probably because you've already gone through the other three domains while working through a similar problem. It may just be something you've solved a hundred times before in your development career.

I personally think the framework can be useful in lots of applications. It's definitely not just useful for startups or new projects. It could be helpful even in well established software projects. I don't believe it's usefulness is limited to the technical world either.

So using this framework is how I stay sane in a world of disorder. I don't panic, I categorise the problem and that helps me stay calm. When I look at a problem and have no idea how to solve it, I know it's fine because it's not in the simple domain yet. I just need to work on it until it gets there.

This was originally posted on my blog in March 2017