Blog

A little while ago I wrote about the Whole Home Audio project I’m planning, which will be a DIY effort based on several Raspberry Pis.

Well, good news! All the stuff I’d ordered has arrived, and I’m nearly ready to get started. Here’s what you see in the picture:

  1. 3x Raspberry Pi Model B+
  2. 3x Raspberry Pi Enclosure (Black)
  3. 3x Dual USB Power Supply
  4. 5x MicroUSB Cable
  5. 5x USB WiFi Adapter (I need four, but I accidentally ordered too many)
  6. 5x Samsung Class 10 8GB MicroSD Cards
  7. 2x Powered HDMI to VGA Adapter, with Audio Out
  8. 1x USB Wireless Mini Keyboard & Touchpad

Not all of this stuff will make it into the project, but I bought it so that I can use the Pis as media playing devices (running Kodi) that I’ll attach to the bedroom TV and the projector if things don’t work as planned.

I bought the keyboard because it would be useful in that regard, and I got the HDMI to VGA adapters because my projector doesn’t have an HDMI input at all, and the bedroom TV doesn’t have one spare. I’d read online that these things draw quite a bit of power – possibly too much for the Raspberry Pi’s HDMI output to reliably supply – which is why I went for a powered model, and why I picked power adapters with two ports each.

I’ve also read that fast MicroSD cards will greatly contribute to the Pi’s performance and that Class 10 is highly recommended. I also read that some Samsung Class 4 or 6 cards have better real-world performance than some of the Class 10 cards out there. I pushed the boat out and got some Class 10 cards from Samsung.

Follow the #RPiWHA Project hashtag on this blog to keep track of my progress. Next week I’m away travelling from work, but I’m excited to get started and start building, so it won’t be too long until the next update.

Blog

A little while ago I wrote about the Whole Home Audio project I’m planning, which will be a DIY effort based on several Raspberry Pis.

Well, good news! All the stuff I’d ordered has arrived, and I’m nearly ready to get started. Here’s what you see in the picture:

  1. 3x Raspberry Pi Model B+
  2. 3x Raspberry Pi Enclosure (Black)
  3. 3x Dual USB Power Supply
  4. 5x MicroUSB Cable
  5. 5x USB WiFi Adapter (I need four, but I accidentally ordered too many)
  6. 5x Samsung Class 10 8GB MicroSD Cards
  7. 2x Powered HDMI to VGA Adapter, with Audio Out
  8. 1x USB Wireless Mini Keyboard & Touchpad

Not all of this stuff will make it into the project, but I bought it so that I can use the Pis as media playing devices (running Kodi) that I’ll attach to the bedroom TV and the projector if things don’t work as planned.

I bought the keyboard because it would be useful in that regard, and I got the HDMI to VGA adapters because my projector doesn’t have an HDMI input at all, and the bedroom TV doesn’t have one spare. I’d read online that these things draw quite a bit of power – possibly too much for the Raspberry Pi’s HDMI output to reliably supply – which is why I went for a powered model, and why I picked power adapters with two ports each.

I’ve also read that fast MicroSD cards will greatly contribute to the Pi’s performance and that Class 10 is highly recommended. I also read that some Samsung Class 4 or 6 cards have better real-world performance than some of the Class 10 cards out there. I pushed the boat out and got some Class 10 cards from Samsung.

Follow the #RPiWHA Project hashtag on this blog to keep track of my progress. Next week I’m away travelling from work, but I’m excited to get started and start building, so it won’t be too long until the next update.

Blog

Yesterday, I wrote about the Requirements 101 presentation I gave to my team about what I believe makes for good solution requirements.

(I was not able to limit myself to the 15 minutes I devoted to this as an agenda item because I like the sound of my own voice way too much, but that’s beside the point right now).

The important thing is that I generated some great discussion, which is exactly what I was hoping for. This was not intended to be a lecture, especially given that there are people in my group who are far better at this stuff than I am. The slide above prompted some great input.

I’d argued that the requirement “the monthly transaction report must be available on the next business day after the end of the calendar month” was a bad one, but I was intentionally tricking people. On the face of it there’s nothing wrong with this, and it was a trick because after soliciting feedback on the requirement and getting everybody’s input I only then let them know that the report in question takes 30 hours to generate and therefore, I argued, the requirement was not achievable. I said that issues could have been avoided by having the right people (probably technical SMEs of some description) at the table during the requirements phase of work.

Some people pushed back and said that if this really was a requirement of the hypothetical project to which it’s attached then work would simply have to be undertaken to reduce the time taken to generate the report. If, on the other hand, the project didn’t have the time and/or budget to support this work then that would be a separate issue to a certain extent, and there would be courses of action other than removing the requirement that could be pursued – but that this doesn’t make the requirement any less valid. People argued that it’s hard (if not impossible) to know that you need some additional technical input at this stage of the process without the benefit of hindsight. “You don’t know what you don’t know,” as one person succinctly summed up.

These are excellent points. In fact, often when I’m helping people document their initial requirements for a project I like to tell them (with my tongue firmly in my cheek) that anything is achievable, it will merely come down to how much time and money they have.

My point in including the example in my slide-deck is that I do believe there are opportunities to validate things like this before requirements are finalized and signed-off by stakeholders. If we are able to take advantage of these opportunities to move conversations like this one forwards in the project timeline then it will avoid back-and-forth between business and technical teams, avoid costly rework, and avoid nasty surprises further down the line.

I still feel that’s all true and that my point is a valid one, but of course let’s be realistic – how much effort do we really want to spend validating that each individual requirement is achievable considering every known and as-yet-unknown constraint (bearing in mind that we haven’t even moved in to the “execution” phase of work at this point in our story and the solution hasn’t been designed)? Should we really wait to secure the availability of a highly-sought technical resource to sit in meetings where they will only have minimal input to provide? Wouldn’t it be more efficient to get the stamp of approval in our requirements as-is and move forwards, allowing the solution architects to identify issues like this later (and suggest where compromises or alternative approaches may be necessary or beneficial)?

I suspect the answer – as is so often the case with the questions I pose on this blog – is all about finding an appropriate balance, but I don’t have any solid guidance here for you all.

What are your thoughts?

Blog

Yesterday, I wrote about the Requirements 101 presentation I gave to my team about what I believe makes for good solution requirements.

(I was not able to limit myself to the 15 minutes I devoted to this as an agenda item because I like the sound of my own voice way too much, but that’s beside the point right now).

The important thing is that I generated some great discussion, which is exactly what I was hoping for. This was not intended to be a lecture, especially given that there are people in my group who are far better at this stuff than I am. The slide above prompted some great input.

I’d argued that the requirement “the monthly transaction report must be available on the next business day after the end of the calendar month” was a bad one, but I was intentionally tricking people. On the face of it there’s nothing wrong with this, and it was a trick because after soliciting feedback on the requirement and getting everybody’s input I only then let them know that the report in question takes 30 hours to generate and therefore, I argued, the requirement was not achievable. I said that issues could have been avoided by having the right people (probably technical SMEs of some description) at the table during the requirements phase of work.

Some people pushed back and said that if this really was a requirement of the hypothetical project to which it’s attached then work would simply have to be undertaken to reduce the time taken to generate the report. If, on the other hand, the project didn’t have the time and/or budget to support this work then that would be a separate issue to a certain extent, and there would be courses of action other than removing the requirement that could be pursued – but that this doesn’t make the requirement any less valid. People argued that it’s hard (if not impossible) to know that you need some additional technical input at this stage of the process without the benefit of hindsight. “You don’t know what you don’t know,” as one person succinctly summed up.

These are excellent points. In fact, often when I’m helping people document their initial requirements for a project I like to tell them (with my tongue firmly in my cheek) that anything is achievable, it will merely come down to how much time and money they have.

My point in including the example in my slide-deck is that I do believe there are opportunities to validate things like this before requirements are finalized and signed-off by stakeholders. If we are able to take advantage of these opportunities to move conversations like this one forwards in the project timeline then it will avoid back-and-forth between business and technical teams, avoid costly rework, and avoid nasty surprises further down the line.

I still feel that’s all true and that my point is a valid one, but of course let’s be realistic – how much effort do we really want to spend validating that each individual requirement is achievable considering every known and as-yet-unknown constraint (bearing in mind that we haven’t even moved in to the “execution” phase of work at this point in our story and the solution hasn’t been designed)? Should we really wait to secure the availability of a highly-sought technical resource to sit in meetings where they will only have minimal input to provide? Wouldn’t it be more efficient to get the stamp of approval in our requirements as-is and move forwards, allowing the solution architects to identify issues like this later (and suggest where compromises or alternative approaches may be necessary or beneficial)?

I suspect the answer – as is so often the case with the questions I pose on this blog – is all about finding an appropriate balance, but I don’t have any solid guidance here for you all.

What are your thoughts?

Shrapnel

I don’t know yet how or if I’ll use this feature, but it feels like something that will be very useful once I figure out what it means to me.

Interesting…

staff:

Look at that GIF up above. That’s a post graduating from the dashboard and living wherever it wants. Like: inside a blog post elsewhere on the internet. Or: on a content-driven site for social news and entertainment. Totally up to you.

Wherever you put it, it behaves the way a post should. It’s likeable, rebloggable, has its tags, is properly credited, all that.

How to do it: From your dashboard, just copy the embed code from a post’s share menu, then paste it anywhere embed codes can go. Enjoy.

What they look like: See these fine pieces from: Refinery29 on Tumblr feminism; HuffPo on the best art GIFs of the year; ET on Parks & Rec; BuzzFeed on SNL afterparties feat. Kristen Wiig and Harry Styles.

Shrapnel

I don’t know yet how or if I’ll use this feature, but it feels like something that will be very useful once I figure out what it means to me.

Interesting…

staff:

Look at that GIF up above. That’s a post graduating from the dashboard and living wherever it wants. Like: inside a blog post elsewhere on the internet. Or: on a content-driven site for social news and entertainment. Totally up to you.

Wherever you put it, it behaves the way a post should. It’s likeable, rebloggable, has its tags, is properly credited, all that.

How to do it: From your dashboard, just copy the embed code from a post’s share menu, then paste it anywhere embed codes can go. Enjoy.

What they look like: See these fine pieces from: Refinery29 on Tumblr feminism; HuffPo on the best art GIFs of the year; ET on Parks & Rec; BuzzFeed on SNL afterparties feat. Kristen Wiig and Harry Styles.