Here’s some pictures from my layout, and some of the electronics that I’ve been working on for the switches.
I’ve been working on using a Raspberry Pi with a previous build originally for my Arduino that uses two 8 bit shift registers to talk to 16 relays. I’m also working with an MCP23017 port expander to be able to wire up 16 buttons to control them locally, for manual operation of the switches. I’ll probably be using more to get some LED status lights on the control board, but that’s still in the air.
As a developer, I often see requests come in for modifications to software that say things like, “I need to see this field” or “I want this name changed from ‘Customer Name’ to ‘Customer'”. Other times I have seen requests that go something like “I want a program that does what this-program-I-saw-at-this-company does”. These requests trouble me, because they are limiting one of the main parts of the system development life cycle, the definition phase. These sorts of requests are the kind that I don’t like, where the solution is given and the problem is unknown. When requests like these come in, I find that it’s important to ask the requester what the problem they are trying to fix is.
Problems are the developer’s bread and butter. The developer is keen to develop solutions to problems, and that is where most of the fulfilment for us comes from. If the solution is already provided, really we’re nothing more than coders, or typewriters that just put down the recipe for what the person requests. Given a problem, however, the developer is free to solve the problem.
For example, I got a request recently to make some changes to the formatting of a report that was used in our accounting department. It was a pretty standard request, but after submitting the report for review, they came back with a list of further changes. Looking down through the email chain, I found that the user was exporting the report to excel, converting the excel spreadsheet to CSV, and then uploading the CSV file to our parent company. The formatting changes were what she needed to make the upload process smoother and the data machine readable by the other end. With that knowledge, we were able to deliver a set of reports that were delivered in CSV format to a shared folder she could access to review and send them from there. The problem was the report was not upload-able in the format we delivered it in. Without looking for the problem behind the solution we were given, a time saving solution for the user would not have been found and the user would still be wasting time converting these reports to a format that she can upload, in other words the problem would still be there.
Give us a solution and we’ll develop a problem. Give us a problem, and we’ll develop a solution.