Good Stories

  • Comments posted to this topic are about the item Good Stories

  • My best stories mostly involve other people.

    Years ago there used to be a CMS call Obtree. Three of us built a mechanism to allow content to be exported to Word so external authors could edit and amend content offline (and in various languages) using a Word template that exported their content in an XML format (this was Word97). They would then email their copy back. The system would automatically read the email, take the attachment, parse it and upload the content with formats, tables, images etc.

    It was years ahead of its time.

    My DB skills came in by reverse engineering the DB and gaining a full understanding of how the product worked under the hood. Documentation for the early versions of Obtree were sparse and badly translated from German. The system worked by a combination of API calls and direct DB interaction.

    Due to the sparsity of the documentation we did a lot using stored procs that we later found could have been done by the Obtree API. However, we tested the site and found that our version ran 5x as fast.

    I really liked Obtree, which went on to be LiveLink and I'm not sure what happened to it after OpenText started rationalising all the CMS's they had bought over the years.

    The best bit was that we worked so well as a team. Had we not done so we would not have taken the art of the possible so far into unknown territory.

    Oh, and we had the system auto-documenting to a web site.

  • In my experience, people are quick to criticize and slow to praise, so it's heartening to see some good stories. Thanks.

  • As a developer, I think your comment about the negativity from deployment is correct; and also it can be down to the fact you are introducing change to long established procedures. I've seen a good in-house tailored solution canned, simply because the users were not engaged (they wanted the interconnected info, but as most were volunteer social workers on a shoe-string budget, they didn't like entering their contribution data). The off-the-shelf replacement didn't engage them either so it was all a shame.

    So my best piece deployed idea (as a Developer mostly with DBA side roles since 1988) was a minibus planner, which was a grid with the dates along the top, and the minibus teams down the side, and the user then dropped in the store that the minibus team was going to stock-check into the right date/team cell (the concept was a collaboration with my manager of the time) Right clicking a filled cell took you to the stock-check details. It was in 2007 with WinForms, SqlServer 2000, and heaven-help-us VB6. Engaging the users to test it was pretty impossible, and the negative side was that 12 people in Hull lost their jobs due to it. But without it, the whole company would probably have gone down and all our 200 jobs...I am still haunted by meeting the staff I'd made redundant when they came in for their exit interviews. Even now, in my current post, I am showing my users a variation on this data arrangement to show their quotes / bookings in a different & informative way.

  • I appreciated your editorial today. You know I think part of the problem of not having a lot of good stories is even when a system turns out really well, there isn't always a lot of praise from co-workers or superiors. It is almost like if something goes wrong then they let you have it, but when something goes right, it is just expected. Kind of like, well you did your job, so we aren't going say, "Thanks!' or "Good job!" because you are just doing your job. Sometimes I think it just has to been enough that you know you wrote the best system, design, database, etc. I supposed in many cases people may not even realize or be able to comprehend what a cool system you just brought on line.

    Ben

  • kerry_hood (6/10/2016)


    the negative side was that 12 people in Hull lost their jobs due to it. But without it, the whole company would probably have gone down and all our 200 jobs...I am still haunted by meeting the staff I'd made redundant when they came in for their exit interviews.

    This is an aspect of IT that is rarely mentioned. I read a blog post where a test manager had worked really hard to engineer a brilliant testing approach that effectively allowed development squads to perform almost all testing. She was somewhat upset when she was called into the office and told that she was being let go as she had made herself surplus to requirements.

    I suspect that if Machine Learning survives the hype cycle we are going to see a lot more redundancies. Entire professions are going to change beyond belief and some may disappear entirely.

    There is a lot of talk on the subject of the role of a tester becoming a hybrid business analyst/tester. Disciplines like TDD/BDD plus the range of things that can be tested through automated means that vastly more can be tested with far fewer staff.

  • Years ago, I was building a learning management system for a law firm I was working for. It was coming along nicely and the firm decided they wanted to try to sell the system through a subsidiary of theirs. I was excited by the idea of income being generated directly from something I was creating. I worked hard to get the application ready for general sale as we signed up to present the app at a large corporate training conference in San Diego. It took a lot of work (I was actually making changes to code on the plane ride out there) but we were ready. The conference went well considering we were brand new players in the space. We generated a few leads which, unfortunately, did not turn into sales as the firm decided they were not comfortable selling software due to risk exposure. I didn't get to see my product sold, but I am proud of that effort to this day.

  • Back at my first assignment as a communications officer with the US Air Force, I was a software developer for Air Mobility Command - the part of the USAF that flies the passenger and cargo aircraft. Our team designed the aerial port systems - the software used to manifest passengers and cargo that were transported by AMC. It was a strange system - written in COBOL and running against a flat-file data management system vs a relational database, running on both PCs (small aerial ports) and a Sun microsystem network (big aerial ports). These aerial ports also had a ground-based element to them, for stuff that came in and was shipped out via truck (which was a lot). The ground transportation used what were called GBLs - government bills of lading - as their documentation. The GBLs were created and managed by another, very old, system run by the Army if I recall correctly. Our functional customers at AMC wanted us to add GBL capability into our aerial port system, but our IT organization's program management was very much against it for some reason (the developers were forbidden to work on any GBL effort). Well, we had a good relation with our functional customer and I ended up working on GBL functionality at home after hours (fortunately this was an unclassified system). Well, about a year into this effort the existing GBL system went tango-uniform (it died for those who don't understand military speak) at one of the main aerial ports. The functional customer went to our program management and told them they needed GBL functionality. Well, the PMs told them that it would take X number of months and Y amount of money to make it happen. The lieutenant colonel lead functional told the main PM "are you sure, I'm pretty sure it's almost ready". Long story short, I was pretty much finished with my rogue effort right at just the right time. We fielded the GBL functionality within like a week and it was a huge success. PM was so mad that we blindsided them, but we were mission-focused and that's what saved the day. Definitely one of my favorite times as a software guy.

  • Reading David Poole's story above made me realize that my first real computer job 30 years ago that I was doing ETL. We had a canned time charge billing system that I think was written in Algol and ported to the PC. I wrote a system that would suck the data out of it in to dBase III+ and produce beautiful reports and invoices, much nicer than the canned system did. I could print 1099s, I wrote an optical bar code scanning system to track file movement through the office, etc. I was pretty proud of that. But it was mostly a reporting system: I still did all timesheet entry and receivables in to the canned system, plus running the monthly close. I had the fastest machine in the building -- an AT with a 286! Complete with self-destructing hard drive!

    Reading the stories above and thinking about my career, I think I've done at least one really good system everywhere I've worked, but two stand out for me.

    I worked for a police department throughout the '90s, and three years ago I went back to have lunch with a friend. I was waiting in the lobby for him to crawl out of the basement, and this guy walks by and shouts 'WAYNE!' I vaguely remembered him. Turns out that a blockwatch grant tracking system that I wrote for him 15-20 years ago was still working absolutely perfectly. It had some tricky stuff in it, and apparently their tracking requirements hadn't changed.

    That pleased me greatly. But what I love is the fact that I wrote it entirely in Access, the data and requirements didn't really need to be based in SQL Server.

    At a previous job for a city gov't they needed an election reporting system. They had one, but it broke and didn't look like it could be easily fixed, so I started from scratch. As I was meeting with the city clerk and a county rep, a very clean three table design started forming in my head (no history was stored -- that was all committed to paper after the election was finalized). I ended up with a SQL Server data store, an Access front end for data entry, and an ASP set of web pages for reporting results. The ASP would cycle through totals for each district, the 'question' votes, and polling station summaries, and just sit there in a loop, constantly polling fresh results from SQL Server as new info was entered via Access. And it ran on the City Council Chambers projection TVs, which fed the City Access Cable Channel, so it was broadcast all over the county. I had it up in less than a month and it worked perfectly. In fact, the local newspaper reporter sent a letter to the city clerk and IT manager saying that in his 40 years of reporting elections, that these were the best election results reporting that he had ever seen.

    It was used twice, then the IT director got in a [liquid reference expletive deleted] match with a couple of other departments and it hasn't been used since.

    Still, I was quite proud of my design. I occasionally think of redeveloping it and putting it up on Sourceforge or something.

    -----
    [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]

  • In a previous career I was a Purchasing Manager. I worked in a plumbing company that was family owned. Basically my job was to keep the sales force happy by having sufficient inventory, while keeping the warehouse (and owners) happy by ordering as little as possible. Too much inventory reduces profits, and insufficient inventory also reduces profits. I would get flack from the warehouse when a truck would pull up because I was ordering too many widgets, and at the same time sales would be yelling at me that we were low on stock on the same widgets!

    Basically purchasing is a thankless job that you must derive your own satisfaction from - nobody ever tells you thanks.

    One year my manager, the president, had to take a leave of absence. At the time I ordered everything but copper pipe, as the family always wanted control over that commodity due to price fluctuations. However the family simply wasn't able to take on all of his responsibilities and so they agreed to let me do it. At the end of the summer they ended up "thanking me" because we didn't run out, and profits were up. They were very happy that I could take on the additional responsibility and actually benefit the organization.

    Software development and administration is pretty much the same. If we get noticed it is almost always for bad things. Lack of notice means we are doing our jobs, but frequently that leads to management wondering what we are here for. If you work in software, you need to find ways to derive satisfaction from knowing you do a great job, while being able to let management know you are valuable. However, being humble is important as well, so it isn't always easy. I try to always give credit to others whenever I can, and I think people appreciate that, which means management sees that I am valuable.

    I do good work, and am hard working. When I make a mistake, the first thing I do is inform my manager, and then the customer. By keeping my manager informed, he is never surprised by a customer calling up and telling him I screwed up.

    Dave

  • Rather than tell my own story I want to relate what we do at Do it Best Corp.

    In the quarterly All IT meetings, the last segment is our CIO singling out people "Caught doing things right". Typically people will email comments and praise to him and he collects them up for delivery. It is definitely his favorite part of the meeting.

    I recall the first time I was called out for something. Being recognized by your management is one thing. Having it celebrated with all your peers is quite another.

    ------------
    Buy the ticket, take the ride. -- Hunter S. Thompson

  • It is not my best story but very meaningful and very current. The day started out as a horror story. We had a problem that basically shut down the entire company. It took an hour to fix the problem and a couple more to clear up all of the minor difficulties that were connected. I felt pretty low knowing I had caused the problem.

    the end of the day ended differently. One of our developers had overwritten what he was working on and Lost most of a days work and lamenting having to redo it. I was able to do do a simple restore from a backup and get his previous work back. The developer was greatly relieved and said a simple "Thanks, I really appreciate this and your work." I needed to hear that after the morning.

  • When I first got into computers I was both in operations and programming, employed as an operator and programming for the company on my "spare time". This was on an IBM 360-30, and when I was nightshift operator at monthend it was a constant cycle of changing 675MB disk packs. It was a fully COBOL shop and there were a number of runs that would take an hour or more per disk pack to process, up to 6 packs per job. The end result of this run would be a 2 page matrix report. My curiosity got the better of me so I asked the lead programmer if I could look at the source code, and explained why. He had no issue but did respond that this code had been running for many years and no one else had found a better way. The COBOL source was itself only 2 pages long, the first 3/4 page being declarations. So I started digging deeper, the program was building an internal matrix of results to produce the 2 page report, so why was it taking so long? I noticed that some of the variables used to calculate the matrix indexes (77-level? my COBOL's a bit rusty) were COMPUTATIONAL-3. COMPUTATIONAL-3 was internally represented as BCD (Binary Coded Decimal) which is great for low volume decimal notation but horriibly expensive for calculations that don't need decimals. So I modified the declarations by from COMPUTATIONAL-3 to COMPUTATIONAL (internal binary) and the runtime dropped to just under 5 minutes per disk pack from over an hour per pack, and the report was identical.

    When I presented my findings there were a few red faces along with the "how do we know it's right? after all our expert programmers never thought of this".

    The end result was they accepted my findings, implemented the change, I quit as an operator and returned a year later as senior programmer.

    These days I'm still in the business of performance, there is no right way or wrong way, just the way that gets results acceptable at that time.

    The moral here is that yesterdays right answer may not be todays best answer.

    A current example is the SQL Server changes for identity cache in SQL Server 2012, which was sort-of fixed in SQL Server 2014, or at least the blatant hole was.

  • In the late 90’s, I was working for an engineering company in project management not in IT support (we didn’t have dedicated IT support at remote worksites). Without going into the details of the engineering job, it resulted in MANY small reports arranged by system/subsystem that had to be distributed to client engineers every Friday for vetting. These reports were required to be submitted by the individual engineering teams by noon on Friday and then one clerk had to sort them, log them, print them all, put the electronic files in the appropriate storage location, write transmittals and deliver all of them to the applicable client engineers by the end of business to allow the vetting to begin first thing Monday morning (no overtime weekend work was allowed by the client and the client's weekly project report included a late delivery metric if the reports were not received by EOB on Friday). At the height of the job, she was unable to process the amount of reports that were being generated in the half day that she was given. The primary tracking tool was a small, custom MS Access database. After seeing her stress out one day, I wrote a fairly basic routine in that Access database that read the incoming network folder to see what reports were there, sort them by system/subsystem (which was part of the filename), log them in the database, print them all with divider pages (a functionality that our printer didn’t have back then), generate the transmittals using MS Word (so they could be saved as a record), move the incoming reports to the appropriate permanent storage folders, and then notify her when the batch job was complete so she could gather all of the paper and deliver it. The total processing time went from several hours to less than one hour not counting delivery time. Senior Management never knew about it, the engineers didn’t know about it, but the difference it made to that one clerk and the resulting positive impact on the project made the small amount of time that it took to write this minor piece of code one of the more rewarding things that I’ve done in my career.

    P.S. It's not just IT that has the issue of unrecognized good work. I've repeatedly seen engineering jobs completed ahead of schedule and under budget that, if they were lucky, got a quick "good job" while problem jobs get tons of "negative press". It seems that people naturally expect a good result and consequently under-appreciate the work that goes into it regardless of the field. It takes real effort to give good jobs the equivalent recognition to the sometimes overwhelming management attention that is given to underperforming jobs.

  • Many years ago I had to sit next to an insufferable know-it-all (who really didn't know anything) so I made it my goal to have him call our Help Desk saying that he'd seen Elvis on his workstation. How did I do this? Some VB code, Winsock controls, weak security in Windows 95 and a flicker of a rockin' Elvis image. Good times, good times. Best thing I think I ever built in my career probably. Guy seemed like he was going to a nervous breakdown after a few days (I had other pranks in there) and... he told our boss he'd seen Elvis.

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic. Login to reply