Crazy IT people

UKworkshop.co.uk

Help Support UKworkshop.co.uk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
A few comments about why some App changes are inevitable:
1. Apps get their data from somewhere (and then process it and present it to the user). If the (third party) data service changes the format of how the data is provided, then the App also has to be updated.
2. Similarly, if the App has to work in new versions of the operating system, that may also force the need for an upgrade.
3. Several small Apps were developed by individuals. If that individual sells / passes the App to another support person, that recipient has to undergo a learning curve and believe me, understanding another persons code logic can be a real pain. Any further change risks errors being introduced.
4. Leaving an App "as is" risks losing market share if the underlying data provider introduces new features which competitors take advantage of.

That said, I'll now go back to my black and white tv, and then to my workshop where I'll continue to work entirely with imperial measurements. (The latter often true by the way for some antique cabinets and furniture.)

I like Spectric's comment! My first computer an IBM1130, with 4k of memory and no disk. An upgrade to 8k and a disk the size of a flying saucer was heaven. However, the code still had to be written to construct a filing system on the disk, load different software modules into reserved storage, support an attached printer etc. Not even a screen, just a keyboard and golf ball console. Every byte and sometimes every bit was used carefully.
 
I never wrote "apps" as such, but made a living of sorts writing embedded firmware. In my experience it was the sales people who were the problem, promising features that were actually impossible because they thought they understood things, or making ridiculous design decisions. It was sometimes very frustrating.
Having said that, they could do something I couldn't, namely lie their arrises off. I would find myself pointing out shortcomings in the product.
 
A few comments about why some App changes are inevitable:
1. Apps get their data from somewhere (and then process it and present it to the user). If the (third party) data service changes the format of how the data is provided, then the App also has to be updated.
2. Similarly, if the App has to work in new versions of the operating system, that may also force the need for an upgrade.
3. Several small Apps were developed by individuals. If that individual sells / passes the App to another support person, that recipient has to undergo a learning curve and believe me, understanding another persons code logic can be a real pain. Any further change risks errors being introduced.
4. Leaving an App "as is" risks losing market share if the underlying data provider introduces new features which competitors take advantage of.

That said, I'll now go back to my black and white tv, and then to my workshop where I'll continue to work entirely with imperial measurements. (The latter often true by the way for some antique cabinets and furniture.)

I like Spectric's comment! My first computer an IBM1130, with 4k of memory and no disk. An upgrade to 8k and a disk the size of a flying saucer was heaven. However, the code still had to be written to construct a filing system on the disk, load different software modules into reserved storage, support an attached printer etc. Not even a screen, just a keyboard and golf ball console. Every byte and sometimes every bit was used carefully.
This implies that the end user is at the bottom of the food chain when as the guy paying for the darned thing he ought to be at the top as the customer. Surely it is not beyond the capability of ITers to maintain the way the app works even though it is updated? Going back to my fuel app, apart from completely cocking it up the only changes I see to it are pretty little fuel company logos all over the place - possibly the app developer derives some extra income from that as advertising, and photos of all the truckstops. As the purchaser of the app these features are not wanted and totally unnecessary, and especially so when they render the app hugely more difficult to use. But then, I'm only the customer so who cares..
 
A few comments about why some App changes are inevitable:
1. Apps get their data from somewhere (and then process it and present it to the user). If the (third party) data service changes the format of how the data is provided, then the App also has to be updated.
The issues started when for some reason we moved from programs to apps, we used to write software programs, not apps and were called programmers so now are the next generation called appliers or what !
 
I never wrote "apps" as such, but made a living of sorts writing embedded firmware. In my experience it was the sales people who were the problem, promising features that were actually impossible because they thought they understood things, or making ridiculous design decisions. It was sometimes very frustrating.
I think the way things are done now causes more issues because a lot of programmers now do not bother to understand a processor from the ground up and are given libraries of functions that perform most of the hardware task so they just assemble these like building with lego and so cannot understand any of the idiosyncrasies within. The other thing I do not like about this is that the source code is not made available so it is just a black box that does something but you do not know how.
 
I think the way things are done now causes more issues because a lot of programmers now do not bother to understand a processor from the ground up and are given libraries of functions that perform most of the hardware task so they just assemble these like building with lego and so cannot understand any of the idiosyncrasies within. The other thing I do not like about this is that the source code is not made available so it is just a black box that does something but you do not know how.
In addition, space is no longer at a premium. A programme that was 150kb could be so bloated that it's now 1GB.
 
Why doesnt the end user feature in all this?
Imagine the app scenario if it related to tools.
You've carefully looked at all the jigsaws in the store and chosen the one with the features you like - oscillating blade, variable speed, etc. You get it home and you're really happy with it. Months later the rep knocks on the door and tells you the jigsaw is getting an upgrade. No use arguing because although you paid for it and chose it because of it features and you own it, the upgrade is compulsory. Somewhere along the line the variable speed function disappears but hey, don't worry about that - look at the amazing new pink with yellow dots casing it's got now. You must be just so happy...
No. You'd be extraordinarily pi$$ed off. So why do we just roll over and accept the same from people dicking around with apps we bought and paid for? I accept that upgrades may be required to keep abreast of the latest operating system developments. I do not accept that profound changes to the functionality of the app are neccessary because of this. I think it's like a dog peeing against a tree - some IT fellow just wants to put his mark on it.
 
Like NewbieRaf I'm an ex IT guy working mainly in infrastructure and operations however in the last 20-odd years I used to typically report to Director types resolving seemingly intractable problems that their usual teams were unable to fix - having more than a little understanding as to how stuff works was often useful in spotting mistakes or misunderstandings between the numerous groups who contribute to a 'product' and who may have little understanding of some of the fundamentals but with significant skills further up the software stack.
The bottom line is this - 'products' or 'apps' are way more complex than most folks would realise and because each comprises numerous modules each written and designed by completely separate and isolated groups the developers or software architects depend on all these components obeying the published API rules for all these modules, and wherever these sometimes complex API's are interpreted there is opportunity for errors to creep in where one persons understanding of how something might work is markedly different to how the original module developer has implemented it. Often it is this aspect that causes things to break when things like updates, o/s or otherwise force change upon an otherwise stable 'product'
Likewise marketing types will pounce upon such forced updates to introduce change such as enhancements or add-ons on the basis that the dev groups are going to have to work on module -X to implement an upgrade, why not whilst you are there implement these changes/enhancements?
All this makes for a very complex env and inevitably compromises and mistakes are made when these changes are implemented and 'features' may be dropped to comply with another groups decision to change their API and drop some function supported in the original and now 'legacy' codebase.
So the reasons why your favourite app change and much loved features come and go is likely way more complex than you realise and in part it is the nature of how the entire environment is incredibly complex, with a huge number of moving parts all changes to which must be tracked and complied with just to ensure it even runs.
Don't get me wrong I'm not defending the industry in the face of the relentless monetisation of 'our' data, however by and large we get lots of cool functionality for free or at least relatively cheaply and the price we pay is that some along the way are making a buck or two out of us - that unfortunately is how today the world works.
 
Last edited:
Problem solved.
All I wanted is what the professionallly produced app used to deliver - to know where the truckstops are in any given area, not segregated by oil company brand which necessitated opening numerous pages, no fancy logos all over the place, no photos, simple to use, no wonderful 'enhancements' and all displayed on a map that opens in my location and not some banana republic in West Africa as the professional app does now after the 'upgrade'.
So easy.
I used OsmAnd Maps as the mapping program and entered on it all the truckstops using the POI map marker function. Click on a marker. On the dialog box to the left of the map is displayed automatically the address and I added POI info, Castrol, Shell, etc and any special details relating to the site, opening hours, access etc. And of course it has the 'navigate to' function. So far I have only set up the Bay of Plenty area, about 30 sites and it took no time at all. There are about 190 truckstops in the country so not a big job. I have saved it as a separate file and made it the default map opening page. In a trial to get a course to a predetermined truckstop, me using my program and the child bride using the app, I had the route, distance and arrival time on screen before wife had even got the app to open.
 
This implies that the end user is at the bottom of the food chain when as the guy paying for the darned thing he ought to be at the top as the customer. Surely it is not beyond the capability of ITers to maintain the way the app works even though it is updated? Going back to my fuel app, apart from completely cocking it up the only changes I see to it are pretty little fuel company logos all over the place - possibly the app developer derives some extra income from that as advertising, and photos of all the truckstops. As the purchaser of the app these features are not wanted and totally unnecessary, and especially so when they render the app hugely more difficult to use. But then, I'm only the customer so who cares..
Largely but not completely true. Sometimes the way the source data is provided (or its content) can force a less than ideal / unwanted change to the App and the IT support person has no alternative but to accept.. As to the customer, many phone apps are initially just "provided" and there is no customer forum - leaving the developer to make his/her own judgement on functionality.
 
The "customer" is the entity who has access to the data that the app is gathering.The "product" is the user of the app. the app is the means to entice the product to use the app and thus amass the data to pass ( sometimes sell ) to the "customer".
Think of the relationship as follows.
you..the app user..= fish
the app..................= baited hook
app writer..............= fisherman
the true customer..= fishmonger

In the case of an app that now requires you to choose the supplier before it shows you the fuel stations, the number of times that the app records that fuel seller x is not the one whose stations you choose ( maybe because they do not have any in the area you are searching ) is of value to fuel seller x. the same apples to fuel seller y and to fuel seller z.
This data about you ( the apps users ) can be sold to each of x , y and z.
Where to have / place ones fuel stations in order to have maximum rentability is very valuable data to have.

Most of the information on Google maps is not about what is where, but is about who has paid Google to be on the map.
 
Last edited:
I'm a website builder but I came from a non-IT background so I've always built with the user in mind. I'd often ask my parents to test things so if they could understand what to do then it was probably good for most people. I was careful to listen to each departments needs for what they wanted output on the website and worked with them to produce a decent product.

I took 6 mnths shared parental leave and they brought someone else in to re-do the websites (again no reason other than a new CEO wanted change). He was absolutely useless and was of the opinion that things had to be done certain ways and it was 'user error' whenever there was feedback that the website was useless. He managed to undo years of careful considered work that I had done in a matter of months. He changed the rich text wysiwyg editors so everyone internally had to use 'markdown' language on the CMS!! Who does that! we have had rich text editors for 20 years and you expect non-technical staff to write in a completely user unfriendly code language. Eventually he had to put proper text editors back on their as it was a nightmare.

Long and the short. Sometimes you get good developers and sometimes you get bad ones and it often depends on who manages to get the ear of the person in charge and whether they are technical enough to know if the person is talking nonsense.
 
Use of this tech goes back way before smart phones and the internet - for a time I worked for a CAD/CAM company which was an offshoot from NASA - it was used to design Challenger, and as well as the usual Oil & Gas and Utility companies as customers was one outfit who used the system to integrate traffic data and mapping to predict petrol station yield and who sold this as a service.
These days I guess it is more opaque as to who is consuming your data or what use it is being put to that raises folks concerns however these days whilst you can opt out of a lot of this the core still remains and one is beholden to the data distributor to honour your own preferences.
 
Long and the short. Sometimes you get good developers and sometimes you get bad ones
But so much comes down to who trained them and where they gained experience in their early years otherwise bad habbits get picked up. A good place to learn embedded software was somewhere using MisraC or Safer C for safety critical systems as it helped discipline the approach.
 
For a lot of developers nowadays ( web or app or systems or otherwise ) all they think they need to know is where is stack, and how to copy and paste calls to Google, facebook et al code or api calls.
Ganalytics* does nothing ( apart from tell all to Google ) that webmasters couldn't either code for themselves or is already in their hosting.
* other spywares that are non GDPR compliant are available..and used ubiquitously.
 
Another factor is that today a lot of programmers are sloppy because they do not have the tight constraints that we used to have when it came to memory and we had to work with kilobytes, if you were lucky there might be a 1 meg ROM.


Good management should keep the workforce gainfully employed and it is often the middle management who come up with daft ideas to make themselves look essential to the business.



Mountain rescue love the smartphone hikers who cannot read maps or use a compass and relie on some phone app, it often gets them into trouble. I tried to help one and suggested that if they insisted on the phone then at least use a decent product with OS maps such as Memory Map which I use on a very old Hp Ipaq PDA. They did not like it because there were a lot of wigly lines and thought it was confusing, they were contour lines which there phone app lacked !
You youngsters!! The first computer I had use of was a Ferrari containing two 1k blocks of core-store!
 
This implies that the end user is at the bottom of the food chain when as the guy paying for the darned thing he ought to be at the top as the customer. Surely it is not beyond the capability of ITers to maintain the way the app works even though it is updated? Going back to my fuel app, apart from completely cocking it up the only changes I see to it are pretty little fuel company logos all over the place - possibly the app developer derives some extra income from that as advertising, and photos of all the truckstops. As the purchaser of the app these features are not wanted and totally unnecessary, and especially so when they render the app hugely more difficult to use. But then, I'm only the customer so who cares..
But are you sure you are the customer - perhaps the oil companies or the truck stop operators are paying for the modifications.
 
More likely the user.
Recently we drove from Whangamata to Matamata, wife navigating with Google maps on her tablet. She reckoned the map was showing a quicker route than the main highway one. When she directed me to turn onto a rutted track across a paddock I had an idea something was wrong. And that turned out to be that she had Google maps set to display cycle routes.
I once forgot I'd altered to walking mode made for an interesting and very scenic route by car
 
Not at all qualified to comment on software, but just on machines & in my experience over the years (I'm not talking Laguna now)
I've come across many 'solutions' and design upgrades to problems that didn't even sodding exist.
Frustrating is the word at times when something changes for the worse. I understand production cost cutting etc, but a design change that is cloaked in 'this is better' when it plainly isn't is head bangingly annoying.
Guess as has been said, it kept certain people in work tinkering with things for reasons known only to them.
Cheers, Nick
 
Back
Top