"I had to individually look up each soldier and then print his license.”
Is this a license to kill?
Still, nice to see that "back-office" work gets recognised
Software engineer and Arizon Army National Guard member Vivin Paliath has explained how writing some Perl and Excel macros saw him decorated with the Army Commendation Medal, a decoration awarded “to any member of the Armed Forces who distinguishes himself or herself by heroism, meritorious achievement, or meritorious service …
Absolutely. I've heard this so many times about Perl, and it drives me mad. Yes, you CAN write obfuscated Perl but it doesn't mean you should. You can also write beautiful Perl. I wish the obfuscated perl competition had never happened, I think it's pretty much killed off a good language.
Having said that, I'm starting to think Ruby or Python are tidier by default.
While its great that he did this work and has been recognised for it there are measures in place to stop this for a few reasons...
I especially like the fact that he downloaded an ODBC driver for the software from the internet to achieve his goal... I assume that this driver was properly checked and certified not to be doing anything dodgy with the data?
Typical management approach. Forbid everything due to security/workplace safety/not invented here/job security for others then turn a blind eye when somebody patches up some code which then gets used 20 years, changed, expanded until it is an even bigger problem than the original ancient program it was designed to work around.
Then start complaining about how proper regulations were not followed and this is the mess that results instead of fixing the original problem.
Sigh.
I'm not saying you're wrong, I've seen some real mess when users with a little bit of excel knowledge are set free to develop their own solutions. But the correct process would have required (in no particular order)... By which time they probably would have started the drawdown to bring them all home again.
A business case (written and reviewed)
A budget
An analyst team to review the scope
Some form of development lifecycle (more than likely swapping back and forth between waterfall and agile)
A team of coders
A team of testers
A deployment team
A development environment
A test environment
A training environment
Outages to deploy to production
Formal sign off
Change review board when it needs reworked to actually meet requirements
Test environment to be updated
Tested
Further training
Outage to production environment
Handover to support team
Support team training
Am I missing anything?
Typical management approach. Forbid everything due to security/workplace safety/not invented here/job security for others then turn a blind eye when somebody patches up some code which then gets used 20 years, changed, expanded until it is an even bigger problem than the original ancient program it was designed to work around.
I missed that - as far as I can tell he updated code (and process) that was more useful. I've gone through that experience - at a hardware manufacturer I worked for, dev wrote test code for bench engineers to verify that stuff worked, but there hardware guys had never been near a production line (or any function that required thinking about usability). I rewrote that code so that a lot was automated which improved not only repeatability but also production throughput, and it cut out bench engineer errors which meant restarting the tests. You have no idea how much flack I got for that from dev, despite the fact that the code did the exact same hardware tests (and I basically had already made a name writing code for this kit). Thankfully, some people recognised that a 50% increased rework rate and production test speed was a good thing, but in those days, coding was hallowed job that should not be handed out to mere amateurs, even if they wrote tighter and much improved code.
As for turning manual jobs into something useful: that same company spent a week typing in the stock list with 2 people so that they could calculate how many parts to send (the process is called "kitting"). So that was 2 manweeks every month spent typing, and with my background in barcoding I already knew of the research that stated that 1 in 300 keystrokes becomes an undetected error (this was 20 years ago). I had a coffee with the guy that ran the vax, and he set up a kermit server for me as a test. Next time we ran the report, I pulled the file in via kermit, cleaned it up with a filter I'd written and then pushed it into a database which then dumped a report.
The result was that I turned 2 manweeks into 15 minutes of computer time (hey, it was DOS and at best an 80286) - and it was as accurate as the stock list was (I also improved stock taking :) ).
However - remember that I told you that coding was for the hallowed developers? Management didn't upgrade my salary, so I left soon after for a job that paid basically double..
"The result was that I turned 2 manweeks into 15 minutes of computer time (hey, it was DOS and at best an 80286) - and it was as accurate as the stock list was (I also improved stock taking :) )"
I think I can do better.
Called in by my boss to look at the part prices spread sheet which has not been update in 5 years.
Our boss is planning to go through this by hand and multiply the costs (because they have not worked out that Excel is magic paper).
Two minutes later I've had everything multiplied by a single cell he can change as and when to update the prices and pointed out this changes everything by the same amount.
It sometimes amazed me he could walk and talk at the same time.
> It sometimes amazed me he could walk and talk at the same time.
:-)
But did it occur to you that a) he's The Boss, and therefore he can b) get other people, such as your good self, to do the actual work, while c) getting paid more?
Maybe not as stupid as he seems when viewed in this light, eh? :-)
Folks, this is why we work in IT. The geniune gratitude of a user for a task well done - be it simple or otherwise - makes up for a great deal of dickheaded twuntery we all have to put up with.
This guy deserves his medal, if only for making something happen in a workplace that, like many of ours, seems to do all it can to prevent anything at all from happening.
Agreed - Though getting an unexpected thank you is always nice :)
IT works in the "shadows" (aka back room), as somebody once said, if the job is done properly, nobody knows about it. Most people only give thought to IT when things go wrong, not when that same IT team is working through out the night to ensure their work does not impact the commercial operations.
There are a lot of people out there like him and it's nice to see someone appreciated. I worked with the IT training team in one company. These people were flying all over the world running intensive courses on the company's software for clients and partners. None of it would have worked well without Sue, a superb administrator, who could book the best flights, hotels, deal with any problem from 8000 miles away, sooth the worries (or egos) of some of the more "sensitive" trainers and techies and ignore the stupider corporate diktats.
A good admin or a problem solver like Vivin should be valued :-)
This really shows up some shocking security practices at the heart of the US army.
They allow ODBC drivers to be setup and installed without admin rights, unaudited scripts to be written and run on the machine. They also allow macros to be created and run on Excel?
Secondly, when someone does this they simply turn a blind eye to it? No security audit, nothing?
Finally the software he was running on was very old and manual entry heavy. From the amount of time that this one guy saved by writing his scripts the army could simply invest in a 'System Usability' division. A group of guys who test out the systems, look for ways to improve them and develop workarounds. Imagine how many man-hours they could save for their guys out in the field who can then spend more time killing people and stuff.