Prototype app outperforms and outlasts outsourced production version We all want the users of our software to be happy, but how far would you go to fulfill that requirement? For one Register reader, perhaps a bit too far. Welcome to Who, Me? "Harry" (not his name for reasons that will become clear) was working as a contractor and doing some onsite development. His team had come up with a nifty …
In 1992 we wrote a quick stop-gap to cover the 9 months before the delivery of the final all-singing all-dancing product to be delivered by a third-party supplier. In retrospect it was some of the best code I ever wrote - compact, efficient, did what it needed to do with no frippery and did it reliably. The third-party was still delivering progress updates but no product when I moved on. I assume that they never actually delivered as I know that our stop-gap was still running in Production in 2015 by which time the building in which it was written had been demolished.
Mid 90s, I wrote a complete queue system in Perl5 aimed at distributed computing.
Reliable, easy to port to new architectures, etc ... And free :)
15 years later, I came to know bits of it was still being used probably because it would cover bizarre cases not usually covered by commercial systems.
Likewise - 6 month temporary stopgap until the big national solution was implemented. Double digit years later it was still running until it got migrated off VB6 onto .net.
Part pride it stood up for so long, part shame because of all the stupid design "decisions" that were made because it was a throwaway.
A year or so after yours, we wrote a ‘quick prototype’ in MS Access for a franchisee. The intention was to evaluate what was required, and that production systems would then be built with PowerBuilder or VB/C with an Oracle or POSTGRES backend for some of the other franchises.
After a month of playing with it, the punter asked why they couldn’t use it in production. It took a few days to separate the forms/VBA/reports into a front-end system, put the back-end data onto a server, and build redundancy. It was good for about 50 thousand rows in the main active table and 5 concurrent users. A couple of extra weeks got the back-end replaced by SQL Server 4.2 on NT Workstation. This was the basis of the system taken up by the franchiser and the rest of the franchisees. As their businesses grew, the central franchiser’s server version had scaled to 10s of millions of active rows with a hundred or so distributed users (some with Terminal Services) by the time I had retired. Other systems used MS Small Business Server. The only problem was that we had to persuade the punters that they needed a whopping 8MB of RAM in each client MS Access PC, when they were used to only 4MB. Smaller systems were able to use existing equipment with the central Terminal Services servers.
Many of our systems for the next ten years followed this pattern, with the clients using the runtime versions of Access. They always came in at a fraction of the cost of VB/C or PowerBuilder, and easily integrated with Excel and MS Word. With a proper installation tool, they were stable enough to ship as shrink-wrap - One product is now installed on over 1,500 PCs on many sites across Australia - Most of our support calls (a few a week) were Windows or networking problems…
In 1969 there was a temporary operating system developed to meet deadlines for an online transaction processing service. It needed a name - so SGOS was born. The "Stop Gap Operating System" was never replaced by the official OS release which was way behind schedule. Oh - the SGOS name was explained by PHBs as "Specially Generated Operating System".
On 2004 I wrote a program to report the daily progress of our railroad maintenance equipment. The reports were important for the customer, the railroad, so they would know that our work was completed on a particular line so they could schedule trains the following day. Originally written as a winforms app in VB.NET, then converted to a web app in ASP.NET (still VB.NET) in 2006. Some tweaks and updates were done but probably was untouched since 2008. It was still in use this year when we sold this division to a new company and the app was gracefully transferred to the new company with the guarantee that it would be only temporary. I may never know how long this app will live on!
Same story: built a "tactical solution" that was only supposed to run for a year or so, before being replaced by part of a multi-tens-of-millions megaproject that one of the big IT integrators was doing. Turned out the big IT integrator's project was too complex to succeed, and got canned before it got anywhere near implementing the functionality to replace my tactical solution, which was still in use 10 years later.
I work in technical support. We keep extensive unofficial documentation on virtually every topic. Every now and then manglement stumble across a document and demand that it gets a formal official release for use.
So far, the process goes: Manglement dislike any criticism or acceptance of problems. Delete 50% of content. Leave positive details in. Make 100 cosmetic changes. Argue for two days about grammar.
End result: all the techies use archived secret copies of the original document.
"End result: all the techies use archived secret copies of the original document."
Ah, that rings a bell. I work for a big IT company, yes IT, so you may believe technical documentation is the bread and butter, here, right ? Right ??
Ermmm, no. I was exposed the documentation "process":
- SMEs create docs (Visio, diagrams), all assembled in a tidy word doc (template)
- the doc group asks a lot of useless people plus the author to sign it with word
- the doc group converts it all as PDF
- the PDF is saved on a sharepoint
I asked the candid question "Can we save, along with the PDF, the doc + any source (visio) ?"
Contemptuous answer: "No, because you could change the signature"
Me: "So, document is frozen forever ? You see how stupid it is, surely ?"
Them: "Documentation shouldn't change"
/double facepalm
At the end, we also used clandestine documentation.
Income tax was a temporary measure when first introduced.
To be fair, the original 1799 income tax (to pay for fighting Napoleon) was abolished in 1802, then reintroduced in 1803 when Napoleon wouldn't stay peaceful, then re-abolished the year after Waterloo.
It was the Conservatives ("the party of low taxation" :-) that brought it back in 1841 and from then on it was always going to be but never actually abolished.
"The party of fiscal responsibility," which, under pretty much every one of its administrations has increased national debt, whilst claiming that it is reducing it, and that "the party opposite" is the one which has done what it is doing, whilst the opposite is true?
If you don't believe me, take a look at things such as budget surplus / deficit over time - those budget surpluses are pretty much all during Labour administrations (with the exception of a couple of Thatcher years, IIRC), and graphs of national debt vs GDP, which sky-rocketed with the financial crash of 2007, but has increased steadily since despite ideologically-driven austerity.
Sounds an awful lot like the UK Scouts system: https://forums.theregister.com/forum/all/2015/01/23/national_scouts_database_at_serious_security_risk/#c_2420265
I wonder how that's going?
I understand the system we're now using in Scouts is a complete re-boot/ architecture following that debacle.
It still isn't the most intuitive system (what enterprise system is) and it is only used for adults; most Scout troops are paying for the external third-party system for young people (where they can afford it).
Wrote a financial calculator in early 00s but wasn't allowed to "write any code". I built it in *cough* Excel. Still being used today; one of the original users of it sends me a screenshot every so often with comments like "I bet nothing else you wrote has lasted this well!". He's not wrong.
I’m retired, but volunteer for a couple of organizations - I find writing them complex business/technical systems in Excel using only “Cell Functions” (No VBA Code, Macros, or Hyperlinks) sufficiently challenging to be interesting. If you don’t mind using an Apple environment, their Numbers products are a fast, easy, way to prototype and then export to Excel.
Oh I have, and I'm fairly certain that many, many people on this forum have as well.
I have bits of code running in several major companies in Luxembourg since 1998. I've got a "backup" ftp process piping data into a mainframe that was supposed to be decommissioned in 2015. There are some more bits and pieces I could mention, but mostly I can say that whatever code I have put in place likely only got replaced when the customer shut down the Domino server for the last time.
I wrote equipment control code in the late 1980's in QuickBasic that I know is still being used because I still occasionally get questions from users of it. There is a whole industry that builds legacy PC's using modern components to interface to old equipment's ISA boards, run DOS or ancient NT versions, and such.
Proprietary stuff costs money.
I keep my Vet's blood machine running. It's an original Idexx Vettest 8008, and is about 30 years old. It is essentially a PC XT clone, with enough kit grafted into it do do blood tests. It's up-to-date, though ... it runs a version of FreeDOS, because MS-DOS is no longer supported.
I know of about fifty of these things still in use here in the SF Bay Area, because I have worked on them. I suspect there are several hundred more. (I bought a bunch of used units 23ish years ago from Vets with Y2K worries ... I was speculating on the need for spares in the future. It was a good guess on my part. I have since augmented my stock by purchasing them whenever I run across 'em.)
...in bed with...
I do not think that either "pointy-headed-managlers" nor "overpaid consultants" are that flexible regarding gender equality in a bed. There may need to be some "in pocket" style rephrasing required to overcome gender specific prejudices associated with both "pointy-headed-managlers" and "overpaid consultants".
I got my unisex coat and am running already
We used to call them "bottom up" systems. They always seemed much more successful than the "top down" stuff that was produced when talking to "Managers”. I learnt to write what looked like two systems (but in reality different menus) - One for the people "doing the work", and one for their bosses (normally lots of reports, and a few fancy templates to allow them to harmlessly squirt static stuff into Excel so they weren’t tempted to "what if" change things).
I used to at least try and get an idea of the processes and flows of what the code I was meant to be writing were. Once you've done a few you can sometimes smell what is really needed and accidentally show the customer something you lashed up once the PHB has been convinced you've written the code in the specs. Its a pleasure when the customers eyes light up as they realise this is what they wanted all along before being dragged through 30 meetings with people who just wanted to take money off them.
I had to write some temporary code in (gasp) Excel VBA to extract data and reformat it so we could invoice the customer. The old manual way was taking 2 weeks man time every month - mine took 10 minutes (and did more). It was supposed to last 12 months while they designed and built something "better".
As far as I know, the code is still being used 5 years later. It just worked! I did fully document it which I supposed helped.
On Friday the "tools" team said it would take about 2 months to date some data and produce reports using their tool.
I worked Saturday, loaded the data into DB2.
On Monday I said "this is what I expect... " and showed them reports and graphs.
They said "What's DB2?" They had spent 6 months + working on their tool
A lot of people complain about VB but in the hands of an experienced programmer you could do stuff in minutes that seemingly take weeks now. An old systems manager I worked with used to love spending as much time as possible being at MS training courses and managed to get us upgraded from MSLQ4.2 to 6 IIRC and came back after four or six weeks of learning the new menu arrangements and upgraded everything and sat in a meeting explaining the new features we'd be able to use in the business only to find I'd already implemented them on the old system simply by writing VB and C++ code to do the things I wanted. I didnt want to show him up in the meeting but he seemed to be hell bent on me writing a lot of changes to my code and having me cancelling a holiday to get it done in time! The code changes took about an hour - just replacing my subroutines with the new bright shiny MSQL6 API calls. It took a lot longer for him to talk to me again!
A decent programmer writing in VB will still prefer to make a decent program. I remember those days quite well, and I had a good job for a while untangling wretched things that barely halfway worked into halfway decent things that mostly worked. VB's biggest fault by far was its buggy, abominably slow interpreter. Once you find the essential tricks to skip obnoxiously slow operations, and eventually figure out how and when to make API calls, VB is pretty functional.
I'm not going to claim it's *good* or anything, don't get me wrong. It also birthed COM and a whole host of proprietary COM UI controls, and that stunk up the Windows API for ages. I'm so glad WMI and a return to C APIs has mostly cast that crap out.
If you are reading this, you're probably using the hack that I put together in 4.1BSD (now called 4.1aBSD) for part of the TCP/IP stack to be included in 4.2BSD[0]. It was supposed to be one of those "Just get us through the demo, dammit!" hacks. I got 'er done over Christmas/NewYears break in 1981. Virtually every version of TCP/IP since has used it. Not too bad for a quick hack.
[0] Just to cut the usual pack of idiots putting words into my mouth off at the socks, no, I didn't write the whole stack. That's why I said "part of". It is only about 120 lines of C in total.
Just out of curiosity, @Jake, have your many travels ever brought you into contact with a guy by the name of Colin Low? I think the network related patents that carry his name may be more recent than your work, by a decade or so, but it wouldn't surprise me if your paths had crossed...
I once created a simulation of the cooling system of a product we were developing, using Excel spreadsheets linked together to calculate individual parts of the system to see how they would interact. IIRC, there were about 30 individual worksheets, some of which were extremely complicated, and the whole mess would take about three minutes to recalculate if a single variable was changed. This was later used to demonstrate the concept to the customer, and when I left the company, it had been dressed up and was being used actually on board the finished equipment. Can't say who the customer was because they have a "shoot first and ask questions later" philosophy.
I was doing a temp job at some small mom & pop shop. I don't remember what initial task I'd been given but I finished far too quickly for their comfort. Boss lady asks me how I managed to finish so fast & I showed her the steps I'd used to do it. She was flabbergasted because her permie employee whom was out on maternity leave that I was temping to replace usually took _days_ to get it done & I'd done it in less time than it took to brew up a pot of water for tea.
Boss lady starts looking around for other stuff that I might do since I had the time. She finds an old to do list that included a bunch of stuff that had never gotten done. She hands me the list & tells me to "do as much as you can while you're here".
Most of it is stupid stuff that's patheticly easy to do if you have any geek genes in your blood. I wind up finishing everything on the list before lunch, except for the very last item. I save that for after lunch & get up to clock out for munchies.
Boss lady asks me about my progress. I tell her that the list is done except for the last one. She blinks at me as if I'd just grown another head & started talking in Klingon. She demands to see. I show her. She shakes her head in amazement & tells me to go enjoy my lunch.
I come back, sit down, & read the action item description to make sure I understand exactly what was requested. It turns out to be a smallish database to keep track of their back up tape library LTO casettes. Tape number, current shelf location, currently # in the que to be used for the next backup, if it needs to be replaced due to age or bad r/w errors, etc.
It's a small office that only had a few dozen tapes. There's no way it needs the full might of their $BigNameDataBase software to get done. So I fire up MS Access & start creating. It actually takes me about 3/4ths of my remaining shift to finish. Mostly because I got bored & started making it pretty once the functionality had been cemented.
About an hour before it's time for me to go I hand Boss lady the crossed off to do list & say "Done."
She tilts her head, jabs a finger at the last item, & asks "Even that one?"
I nod & show her that it does what the system requirements specified, that it's currently using a few automated scripts to keep itself up to date every ~5 minutes, & should continue to keep working as long as the computer it's on continues to function.
Another open mouthed, head tilted, gaping like a landed fish moment. She thanks me for working there that day but informs me that "you've just worked yourself out of coming back. I had figured you would need a week. You did it all in ONE. STINKING. DAY. ... There's no point in coming back in the morning, there's nothing left for you to do!"
I shrug, smile, thank her & leave...
Fast forward to early 2002~2003 & I get a call from Boss lady. They want to know if they can sell copies of the "program I'd written". I inform her that it's not up to me since it's an MS Access database kludge. She sighs & grumps "Figures. It's been running flawlessly for all these years. It's probably the only thing IN this place that HAS. Thanks anyway. Bye." *Click*
I've posted this anon because I don't want to openly admit to having used the damned program, much less that a Microsoft product somehow managed to keep working for over a decade.
*Headdesks repeatedly in angst*
I have at times had roles where when asked what my job is I reply "To make myself redundant!"
The idea being to solve all the problems and make the setup simple enough and reliable enough that I'm no longer required.
Only ever got close once, where 4 months after joining I'd already finished off 90% of the 2 year job list my boss handed me when I started. And the only things left were fluffy filler jobs. And since I don't do "day-to-day" office jobs I chose to leave a well paid job (where they wanted me to stay) rather than let my brain start to dissolve by having to do the same menial office tasks cos there were no IT tasks left.
I worked for a small council where the staff had avoided being outsourced by not revealing the secrets of their job to contractors and so had one of the smallest most efficient IT depts, For some reason I got employed there and one of the originals was on holiday and I needed to access some data in a program of hers and so did a bit of digging, sussed it out and got what I needed to do working. The look on her face when I told her what I'd done was a picture. I did also inform her that here secret was safe with me and the code I'd written was lacking my normal detailed comments and left it in her capable hands and wandered off into retirement.
Since you added a question mark: Yes.
One of those attitudes takes a constructive pro-active collaborative approach to their work, gets to encounter different teams, people and technologies, builds a broad skillset and gets to enjoy the difference they make.
The other works in fear.
An old friend once had the task of automating a form-processing procedure that took forms from one group of managers and wrote it down on different forms for a second group to deal with. He simply redesigned the initial forms so that once filled in, they told the second group everything they needed. His job then comprised waiting until it was time to go home, then moving all the day's forms from his in-tray to his out-tray before putting out the lights.
It was many months, during which time he truly mastered the art of firing bent paperclips into a pinboard with an elastic band, before he was officially made redundant.
A suitable pause later, around 0.7 nanoseconds at most, his forms were declared unfit for purpose, a new clerk with fewer scruples recruited and the old forms reinstated.
You can win the battle, but you can never win the war.
There may be little wrong with MS Access "when used appropriately". I would suggest that the learning curve for writing and deploying reliable systems in Access is both long, and steep.
I have an immodest self-serving post above this one, outlining some MS Access systems. Possibly because I started doing stuff >50 years ago with FORTRAN and Dartmouth BASIC, then built more complex stuff with Rdb, Sybase, Informix, Oracle, etc., on large minis, I’m aware that I may not always have produced some of the fragile overcooked spaghetti that one might expect from some MS Access systems…
But this generally means that the problem wasn't as difficult as it was thought to be, and therefore your "prototype lash up" was actually an acceptable solution to the problem, as opposed to the problematically over-engineered production tool.
Personally I'm happier with the more complex systems I worked on that did need proper up-front analysis and design, but still worked well (and were easier to maintain over their lifetime as a result of that design work).
2008, consultant is brought in and says he can do X with the project but it'll take about 18 month to 2 years to fully deliver. My manager pulls me aside and gives offers me 2 weeks to "play" with some ideas. 4 days later a colleague and I have a working solution that did about 90% of what was required with plenty of scope for expansion. A month later the "lash up" is in production where it is still ticking along to this day in 2022. The consultant they hired? He lasted just 2 more months and was gone, very quietly left and never seen since.
Like several other people I once developed a code generator for Informix 4GL which would delve into the system catalogs and put together some generic but table-specific code for basic retrieval, update and deletions which could then be augmented with application-specific code. At that time Informix SQL didn't have a scroll cursor so it was largely prompted by the need to provide an emulation of this to enable the user to scroll backwards as well as forwards through the retrieved rows. It had some placeholder prompts in it which would be replaced by something more application-specific when the program was worked up.
I took this with me on several jobs. One which I've mentioned before, in a software house, needed a lot of work to disentangle an application which was one mess of Informix Perform screens into a set of discrete 4GL modules using the core generator to start things off. As I've also mentioned I parachuted myself out of that job leaving some of the modules as work in progress with default prompts in there. Roll forward to early retirement out of that subsequent job and into freelance.
One of the freelance gigs was to oversee UAT for a migration to a new server for an organisation in the field that that system was aimed at although I didn't recognise the application name. This was about 10 or 11 years since I was working in that area. Standing in reception when I first arrived I could see some of the screens in the distance & thought they looked very like how I liked to lay out a 4GL screen. Sure enough, when I got there it was my old application having been through various name changes. The default prompts were still there in the stuff I'd left as WIP and so, I think, was the scroll cursor emulation although the Informix engine had had that for years now. A couple of years later I got called back to repeat the gig for another server upgrade. Still all the old stuff left in.
Knocked together a system for a 6 month 'pilot', to help determine if / how processes would best work when converting a manual workflow to a digital one, with the idea the users would note the bits that worked well, what didn't work and what else might be needed to make it quicker and simpler for everyone involved.
That was 2013...
A long time ago - prior century - I put together a system to help automate the production of a listings magazine - they'd previously laboriously retyped the listings every month. It consisted of a database that contained the repeating events and an export that could be merged with a template into the page-layout software. It was knocked together on a shoestring but had a lot of subtleties to do with the compact written expression of event schedules for one-off, short-run and long-lasting events (3rd Tuesday at 4.30pm or Mon-Fri 9am-6pm, or 1st, 5th, 19th & 21st at 11.30pm, or June 20th-August 15th 10:00-16.30) and the best way to represent them. I understand it was reworked for a different platform when the information went online as well as being in print, but after much head-scratching the new team decided the best way to approach the problem was to replicate the original code as far as possible, in another programming language, keeping exactly the same database structure, export format and templates. Last I checked, it still lives on in its same-but-different form.
I once wrote a system for a well known tech company. Total size was around 8mb. (yes megabytes).
It was replaced by a system over 40GB in size (yes gigabytes). new system did basically the same thing as my system, but every now and again would just up and randomly delete customers TV/broadband accounts, cutting them off randomly.
Eventually it was decommissioned (think slightly over 12months later and £150 million spooged down the drain) and my system went back into use.
In the early 90s, I was working as a Temp for British Rail. I worked in the local Quantity Surveying department, and they had a computer system for tracking requests for maintenance across the South Eastern network. Our office was responsible for maintenance for all the stations in Kent but not those in Zone 1. The system they had stored all the requests in a database and used various spreadsheets to show the data in an easier to read format. From a technical point of view, nothing really complicated, but it had a horrible interface. After a couple of weeks, I'd had enough, and in my lunch hours, I started working on an alternate interface. I showed it to my boss, and he liked it so much, he immediately ordered that the system use that interface. Unfortunately, it was so easy to use that it backfired on me, because he asked me to train my replacement in it. While, being a temp, I figured I was going to be replaced at some point, I'd not been told that I was.
Still, I am told that the system lasted until British Rail was wound up, and the responsibility outsourced.
At $oldjob, I hacked together a tool for inventory planning. It was written in VB.net and mined info from Sage's database [15 minutes of dealing with Sage PTSD here...].
I made minor improvements to the tool over the years, but didn't put much effort in because we were covering to a new ERP system. Like most ERP conversions, that was a death march project. I was able to leave the job before becoming a scapegoat.
About 3 years after leaving, I got a call from $oldjob's MSP. They were updating the servers, and needed some help to point the tool to the new DB location. I was able to talk them through it.
At $currentjob I was in a meeting recently where someone mentioned a limitation of our current MRP system. I was smart enough (barely) to not offer to write a similar system here.
Any quick fix for a specific issue that actually works according to the user requirements will be used and kept. So best make it nice and efficient and robust. How many 'bodges' have attained undead status and eternal life because nobody dares to turn them off?
Half of the current legacy systems probably started out as quick fixes or short term demonstration systems, shortly to be superseded by the full professional production version. (And 'RFC' actually stands for "Request for Comments", but the Internet seems to run on them.)
Either make it robust, or make it stop working after a month, so it HAS to be done properly! Be ruthless, store dates as a number between 1 and 30...
Relatedly, I try to write "permanent" programs with some change-in-specification headroom. Not too much, I don't write a new (simple) programming language to implement the project in... usually...
this story reflects my programming life
"Just need a quick and dirty prototype pushed out the door to keep XXXXX customer happy"
One quick and dirty program later
"Customer wants 10 more"
Rerun quick and dirty program 10 more times
18 years later and a change of machines, but the same old program
"1000 more this month".....
Wheres the "I want to retire" icon?
Harry would have surely been aware that the managers in the CC list had no idea that an edit history even existed, never mind how to bring it up. And even if they had accidentally clicked the History tab, the plethora of geekology would have scared them away instantly.
Anybody capable of spotting the ruse would have been on his side already.
A "new version" of whatever is being replaced never arrives. Developers cannot possibly keep up with those wishlists, so the product either never leaves beta or is released in such a buggy state it creates a groundswell wanting to go back to whatever preceded it. Only if "whatever preceded it" has left the building on its way to a scrapyard will the buggy new version remain in place.
I wonder if a lot of the time our old friend Pareto comes into play. A quick and dirty prototype which delivers a substantial amount of the functionality can be done very quickly, but the last bit takes all the work. If you add to that the old problem of changes/new features being added faster than the system is being developed then its easy to see how the production system can get stuck in development hell while the proto keeps doing its 80%.
Was this article a summation of mictosoft and all of its products?
Anyway, I whipped up a little database while I was working for a local government using Access97. I needed help from professional programmer on staff to properly split the database but still have access (what a good name for a simple database) to both halves. The db tracked around a hundred contracts and the split was to separate the active ones from the inactive ones. It worked far better than the cobbled over db we used to tract taxpayers and didn't crash. Plus, the reports were fully customizable. The other was all text based and the reports were predefined.
I did build a small Access database to see if it would do what the text db would do. It did quite well until the boss had a fit that I was trying throw the professional db under the bus and that mine would never work.
Not bad for someone who had no training in Access. And then mictosoft changed the who bleeding kit and nothing worked the same.
I do a lot of work porting older stuff that has been around for ages to new languages and platforms. I can you in most cases where the original dev looks back and thinks their code rocked most certainly has the rosiest tinted glasses ever. Usually the code will work very well but it definitely sucks. Especially VB based stuff.
Quite a lot of the old VB crowd are out there writing pants PHP code now.
I can always spot a former VB coder a mile off in their PHP code by their constant use of camel case and their elaborate functions to deal with stripping carriage returns and swapping spaces. :)
For the love of god guys, if you keep insisting on nicking the work off us young uns, at least have one of us relatively young uns as a wingman to ensure your code is up to snuff using proper library management etc and give yourselves breathing room when the customer raises the age old "what happens when you get hit by a bus" routine.
Most of your customers will bring one of us in as a second opinion / backup anyway so you might as well have us on your side than their side. I would much rather help make a product better and fight on behalf of the dev, than be hired by a firm to hammer the fuck out of their contractors for no reason other than that's what I've been paid for!
It sounds to me like the "prototype" was built using what a lot of us would recognise as lean and agile principles. They added features requested by users, they delivered working software regularly, they built things that were wanted rather investing heavily in a speculative architecture "because it will need to do X in the future". That's what agile should look like, not something imposed on you by an "agile coach" with a ton of certifications.
Loads of good techie war stories...from the users viewpoint....
1. This is a total pain... wish there was a way to do it easier
2.This spreadsheet does the job, but it's impossible to work with more than n rows, but that nice lad on the help desk hacked some code in access
3. Oh that looks nice...
4. We ought to get the IT guys to give us a proper tool for this
5 Oh, they said there was no budget this year.
6. Oh, they can do it, but we'll have to find £x in our budgets
7. Great news, they are going to do it, but not this FY
8. Nor next
9. Oh here it is - I know...it looks a bit clunky, but honestly CTRL-BACKSPACE-Q is actually a perfectly logical way of confirming you have saved your edits and synching the display with the back end.
10. This is a total pain... wish there was a way to do it easier, wait a minute, we still have the old app....
Reminds me - one OS extension I wrote -74 retired 2020, z/OS changed too much, but since then always better than what OS itself could offer, so just have to love the old OS/360 idea! Write once and then compile and it works again, even through all the HW changes! And not even talking about applications - they should work forever if done right!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
