March 15, 2016 at 10:17 pm
Comments posted to this topic are about the item The Math on Automation
March 16, 2016 at 3:07 am
There is no harm in part automation i.e. automating part of a task. Over time this may lead to a fully automated task. Or it might not. Either way automating what makes sense is valuable. Automating anything else may be an act of futility.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 16, 2016 at 4:41 am
The key phrase for me was "one of the main powers of automation is consistency and repeatability. "
It means I do not have to remember the steps in what might be a complex process.
The other thing is that writing automation for a task is usually more interesting than performing that task yourself.
And the automation will probably be quicker than you - useful if there is an unexpected spike in demand for that task (as has happened to me shortly after I finished automating a task).
March 16, 2016 at 4:52 am
I'm a massive advocate of automation (a lot of my job looks at automating repetitive tasks) - but would note that: "little scripts to save time are definitely valuable" - should also say "but need careful management, documentation, rigour and a strategic framework that doesn't orphan them from the rest of the solution"...
Or maybe I'm just too big a control freak 😀
March 16, 2016 at 5:06 am
chris.dodgson (3/16/2016)
I'm a massive advocate of automation (a lot of my job looks at automating repetitive tasks) - but would note that: "little scripts to save time are definitely valuable" - should also say "but need careful management, documentation, rigour and a strategic framework that doesn't orphan them from the rest of the solution"...Or maybe I'm just too big a control freak 😀
If you're being a control freak, then I am too. I'm also in favor or automation. Yes, helper scripts are, well, helpful. Anything that can be done to prevent mistakes is a good thing. The time savings can be huge and is normally worth the investment of time, but accurate results are important in most anything. It also frees you up to do things other than babysit a process for the next 4 years.
March 16, 2016 at 6:47 am
If it is within your power then design stuff to be automated.
I've just spent months trying to get a system that will be run by a very small team to the level of automation where it can be managed by a very small team without the administrative process becoming their job. I want my team to use the systems not be burdened by the systems.
I'm finding that some commercial software is highly resistant to being automated. Other software is fairly well behaved up to a point but push beyond that point and your world becomes one of pain.
Basically, what you need is a well defined object model and API for your software if you are going to want it automated and that isn't a trivial thing to write.
March 16, 2016 at 6:52 am
I find myself constantly automating things, everything. But to me automation means more than creating something that does a task for me so I don't have to, the traditional hands off kind of automation. To me it can mean using the ctrl-shift-arrow keys to quickly highlight text rather than shift-arrow to slowly highlight that same text. I am always trying to find a faster way to do a task I do often, so I can save time and do more. I am always wanting bigger monitors so I can see more stuff at the same time and not have to move the various software screens around. Even when I walk I'm looking for the shortest path so save steps and get to my destination faster. Where I fall off the wagon a bit is my communications. I can get wordy in my emails. But I justify that as I want to make sure I address all possible questions up front so I don't waste time with multiple back and forth emails. Oh, and I do try to automate tasks with code, don't want to forget that.
March 16, 2016 at 7:20 am
David.Poole (3/16/2016)
...Basically, what you need is a well defined object model and API for your software if you are going to want it automated and that isn't a trivial thing to write.
That's some great 90's thinking there (not an insult). As soon as rapid web development became flavour of the month we seemed, as an industry, to lose the perspective that this has amazing long term value.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 16, 2016 at 8:30 am
Automation is a good thing. As pointed out, it reduces error as long as the inputs remain consistent to the design.
Here's the thing: any code that we write we do not write for ourselves, it should be written for those who come after. It needs to be documented, maintainable, and reliable. Some day someone else will take over our job, and just how well was that one-off process documented? If it's properly automated, it should continue running after we're gone and our account is disabled.
Only looking at the time required to automate something can be rather short-sighted.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
March 16, 2016 at 9:00 am
We know that humans are bad at being consistent and reliable, and those are the places we should use computers. Even if the time savings don't directly add up,
Basically this is true, assuming that the job is done more than just rarely and is pretty much a known entity.
Humans do have one advantage over code in that they will often recognize when a result does not make sense. Especially when jobs are done on an occasional, or ad hoc basis, a human will often recognize when the result is off because of a condition that the original coding did not anticipate.
Couple of (humorous) examples from the past.
People (!) began to notice that no one was ever picked for jury duty from one particular town. Further examination showed that ALL the inhabitants of that town were 'dead' -- actually the last 'D' in the town name had spilled over into a status field and they were all categorized as deceased. Code saw nothing odd about a town full of dead people.
Another example is that a truck received a couple hundred speeding tickets in a single day. The automated speed trap/license reader would capture the plate ID of a truck doing maintenance while it just happened to be parked by the camera. The automated system saw nothing suspicious in sending out summons after summons to the very same vehicle.
...
-- FORTRAN manual for Xerox Computers --
March 16, 2016 at 9:34 am
Wayne West (3/16/2016)
Automation is a good thing. As pointed out, it reduces error as long as the inputs remain consistent to the design.Here's the thing: any code that we write we do not write for ourselves, it should be written for those who come after. It needs to be documented, maintainable, and reliable. Some day someone else will take over our job, and just how well was that one-off process documented? If it's properly automated, it should continue running after we're gone and our account is disabled.
Only looking at the time required to automate something can be rather short-sighted.
Agree, though I think some level of competency should be assumed when documenting. I'm not writing enough for a new grad or my Mom, but for someone that understands SQL Server (or C# or PoSh).
March 16, 2016 at 9:35 am
Gary Varga (3/16/2016)
There is no harm in part automation i.e. automating part of a task. Over time this may lead to a fully automated task. Or it might not. Either way automating what makes sense is valuable. Automating anything else may be an act of futility.
For sure. I do this all the time. Some manual, because it varies enough that it's hard to automate, and some automated.
March 16, 2016 at 9:36 am
Iwas Bornready (3/16/2016)
I find myself constantly automating things, everything. But to me automation means more than creating something that does a task for me so I don't have to, the traditional hands off kind of automation. To me it can mean using the ctrl-shift-arrow keys to quickly highlight text rather than shift-arrow to slowly highlight that same text. I am always trying to find a faster way to do a task I do often, so I can save time and do more. I am always wanting bigger monitors so I can see more stuff at the same time and not have to move the various software screens around. Even when I walk I'm looking for the shortest path so save steps and get to my destination faster. Where I fall off the wagon a bit is my communications. I can get wordy in my emails. But I justify that as I want to make sure I address all possible questions up front so I don't waste time with multiple back and forth emails. Oh, and I do try to automate tasks with code, don't want to forget that.
I do some of this, but I find if I do too many keystroke things, I start to confuse them
March 16, 2016 at 10:38 am
David.Poole (3/16/2016)Basically, what you need is a well defined object model and API for your software if you are going to want it automated and that isn't a trivial thing to write.
While that would be ideal, even a modest exposure of a tools capabilities to manipulation by software can yield benefits. One of the big advantages of automation is that it can extend the use of a tool in ways that were never conceived when the tool was created.
I used to work in a company on a large system written entirely in assembly language. System crashes were normally investigated by writing a complete memory dump to tape, loading it into a program which would print the entire dump to paper and then using the source listings (with both assembly and machine code listed) with a large cross-reference of the system's symbol table to identify module and symbol locations in the dump to troubleshoot the problem.
I hated having to print out that huge dump every time when frequently the problem was found after examining only a few pages of the dump so I looked to see if I could get the dump program to print only a portion of the dump, allowing me to identify the likely area of interest up front and attempt to print out only what I actually needed to see. Once I looked into the program I discovered that it not only would allow me to dump any portion of memory I liked, but it actually created a disk image of the dump first and worked from that so I could dump multiple sections without having to reload the tape. That inspired me to create editor macros to manipulate the dump and the symbol cross reference directly from the editor so that when I loaded in a module's source code it would open a window with the module's memory dump as well. I could highlight symbols in the source and press a key to dump out the value of that variable on demand. I could highlight a symbol in a call or jump and load both the source and the dump of the called routine on demand. It made dump analysis incredibly easy but clearly was never part of the original conception of the dump tool -- but because a little flexibility had been included in the tool's design I was able to use it in a new way.
A full API and object model would be great, but just thinking and designing things with a little bit of abstraction and flexibility can go a long way with a bit of ingenuity.
- Les
March 16, 2016 at 11:13 am
I was rather impressed with this automation (assuming it's true).
A programmer wrote scripts to secretly automate a lot of his job — and email his wife and make a latte
http://www.techinsider.io/programmer-automates-his-job-2015-11
🙂
Garrie Powers
IT Developer
Comprehensive Clinical Trials Unit at UCL
Institute of Clinical Trials and Methodology
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply