How many Windows and linux computers are in service? How many iOS and (to a lesser extent, macOS) devices are in service? Swift addresses a different marketplace, the mobile market, which is growing faster than the desktop and server market. There's also money to be made by developers using iOS while all the other mobile OSes make chump change. Android is difficult to develop for because there's a million different versions, most of which never get updated or patched. If I had any input into what students should be developing with and for, especially in the US, I'd strongly suggest Swift and iOS (macOS has the benefit of being closely related). Animation is a huge business and Apple products and operating systems are addressed by the primary software developers. I would never suggest someone bore themselves to death writing business software for Windows or linux.
iOS apps are 99¢ professional business software can run in to the thousands. There are all sorts of profitable niches in software development. Remember the trucks and cars analogy? iOS devices are by in large consumer devices. If you walk into just about any business you'll see a full computer on every desk. Sure, iPads can be used in business, especially when out in the field, but for every person you see using one, they most likely have a full desktop computer in their cubicle back at the office.
Most "business software" are developed in house by analysts and have nothing to do with being sold at all, which is dying model.
The rest of business software, the one sold privately, is now moving to subscription models, run from the cloud, which ahem, costs more than $1 per month.
You're building a straw man.
End point workflow where the desktop ruled is also dying, even a small 12 inch business laptop (the very expensive ones) don't usually run traditional full suite.
The fact there was no way to do work properly before outside the desktop is what led to the workflow we had for 30 years and that is why software were that way.
Now, people are on the move, manipulating and consuming data at many place, many time, workflow change and the software changes.
More and more of the content will be manipulated in smaller pieces, by smaller apps working to fulfill one goal.
Uhhh, well, no... You bought into the advertising and the hype -- which is focused on selling available products....
For major corporations: Business workflow didn't derive from product availability. Business products were and are derived from functional need. Very simply: You aren't going to manage a billion inventory, a multi-million dollar accounts receivable or payable, or get out a payroll or manage employee benefits packages on an iPad in a coffee shop.
And, the business systems and hardware to drive those functions are, to a large extent, purchased packages. Admittedly, they are multi-million dollar packages. But still, they are purchased packages. Yes, there are systems developed in house. But, due to the high cost of development and support, that is only for those functions unique to a particular business.
The biggest budget is on integrating the hundreds of flavors of the day software bought over the years and just trying to piece those things together and keep them alive means your "workflow" (sic) has to be forged around a historic mound of dung.
You do know those POS "enterprise" software are associated to a bundogle of internal integration done in house that may last many years.
For example, IBM put in the Phenix system in Canada which cost 1B, cost another 1B internally (gov workers doing the work) and still doesn't work.
Those "purchased" packages NEVER work correctly as is NEVER and always take more resource internally to make work.
.I've yelled at vendors and consultants so often I probably damaged my vocal cords.
So, no, workflows are not well thought out and well matched to the company. They make do with what they can.
If that was the case, most companies wouldn't be running 10-20 year old software in this day and age.
People and company are stuck with sclerotic workflows that often are the reason why they are inefficient and it may even kill them.
It's not a choice, it's not the most efficient and people complain about it ALL THE TIME.
What happens, a new guy comes in, he gets part of the system replaced, integration goes over budget, it takes way longer than supposed to, bang he leaves and the next guy decides to scale down or switch to some other genius solution.
Often, instead of trying to fix those sclerotic workflows, it's easier to just pop out some functions, especially new ones, out of it and run them in parallel (that's always been the case but his has been accelerated) to deal with things that traditional workflow could not deal with.
I've run large organizations with very large budgets and been in the industry since the 1980s, so you can try your haughty tone on your children.
So have I. Actually, since the 70's. And, like you working at the highest levels in and with large organizations (mostly Fortune 100 & 500) and multi-million dollar systems. But, I never had the experience that you relate. Luck I guess.
Yes, it is luck, I worked as a consultant, as a computer, system and software engineer (with the diplomas to match) in computer security, and in creating and building up retail products, enterprise products (large scale NAS) and server based client services (in telecom and outbound telemarketing platforms), plus got decades of various management (mostly CTO these days).
The only one who is drinking the koolaid is anyone who thinks those enterprise "packages" or large scale software are one and done when you buy it.
Most consultants I found must never be trusted at their words; like the old adage from the cold war said. Trust BUT verify. And working as a consultant for 6-8 years in the early 1990s didn't make me change my mind on this.
There is a reason why the industry is quickly moving away from those monolithic software that are hard to install, are hard to maintain and hard to change.
The return on investment on these kinds of things aren't too rosy if they can be quantified at all and the project risk is very high,
Enterprises tend to want to rollout services more continuously, starting with core functions. That matches well with agile dev and lean enterprise principles.
Spread out risk by leaving the waterfall development (or delivery) behind, get the highest benefits early by concentrating on key functions and features, get other functionalities out as soon as possible to get feedback to correct.
Actually, it wasn't luck. It was reality based honesty and hard work by myself and others to recognize and deal with the very real pitfalls that you mentioned...
But, on the other hand, there was luck involved in that I was consistently able to work with people above and below me that worked together as a team with common purpose to do that. I could not have done it without their support -- Or, more correctly: We could not have done it without our support.
The best example I can give is when I was first hired into a start up IT company with the goal of having me lead a team to design, build and support a custom inhouse automated invoicing system. After doing a thorough analysis I gave a presentation to corporate executives where I told them it would be overly expensive to build. And then, they would hate it because it would be expensive to maintain, be cumbersome, and lack the flexibility they needed. And so I recommended instead that they use speadsheets to do the work semi-manually (all the while thinking that I had just analyzed myself out of the job I was hired to perform). To my surprise, the executives bought it. But the Controller hated me for the next 10 years -- until we were bought by another IT firm who had built exactly that! And, even though it was a quality (but expensive) build, it was an albatross for the very reasons I had predicted... The Controller, once he got a taste of it, (grudgingly) finally admitted I had been right!
Am I haughty? No, no more than Steve was. Like me, he was proud of what he did. But his humility drove the process from the knowledge that it was hard work and brutal honesty by he and others that made those products what they were. (And no, I am not comparing myself to Steve. Just pointing out that we shared some common attributes)
Actually, it wasn't luck. It was reality based honesty and hard work by myself and others to recognize and deal with the very real pitfalls that you mentioned...
But, on the other hand, there was luck involved in that I was consistently able to work with people above and below me that worked together as a team with common purpose to do that. I could not have done it without their support -- Or, more correctly: We could not have done it without our support.
The best example I can give is when I was first hired into a start up IT company with the goal of having me lead a team to design, build and support a custom inhouse automated invoicing system. After doing a thorough analysis I gave a presentation to corporate executives where I told them it would be overly expensive to build. And then, they would hate it because it would be expensive to maintain, be cumbersome, and lack the flexibility they needed. And so I recommended instead that they use speadsheets to do the work semi-manually (all the while thinking that I had just analyzed myself out of the job I was hired to perform).
So, did they have an IT department within the company that maintained the spreadsheets?
I have seen implementations where user departments used a spreadsheet solution to get results because the company's IT department had a backlog of 1-2 years to implement a custom automated system...
The user departments became little silos of spreadsheet expertise and evolved into little autonomous Spreadsheet IT departments -- each with their own backlog...
Even worse, based on the early success of the spreadsheet solution, the protagonists got promoted or left the company...
The little autonomous Spreadsheet IT departments did not have the professional IT experience, procedures, etc. [overhead] -- so there was no rigorous process to maintain the spreadsheets and train backup personnel...
The spreadsheet solution, became worse than the problem!
Actually, it wasn't luck. It was reality based honesty and hard work by myself and others to recognize and deal with the very real pitfalls that you mentioned...
But, on the other hand, there was luck involved in that I was consistently able to work with people above and below me that worked together as a team with common purpose to do that. I could not have done it without their support -- Or, more correctly: We could not have done it without our support.
The best example I can give is when I was first hired into a start up IT company with the goal of having me lead a team to design, build and support a custom inhouse automated invoicing system. After doing a thorough analysis I gave a presentation to corporate executives where I told them it would be overly expensive to build. And then, they would hate it because it would be expensive to maintain, be cumbersome, and lack the flexibility they needed. And so I recommended instead that they use speadsheets to do the work semi-manually (all the while thinking that I had just analyzed myself out of the job I was hired to perform).
So, did they have an IT department within the company that maintained the spreadsheets?
I have seen implementations where user departments used a spreadsheet solution to get results because the company's IT department had a backlog of 1-2 years to implement a custom automated system...
The user departments became little silos of spreadsheet expertise and evolved into little autonomous Spreadsheet IT departments -- each with their own backlog...
Even worse, based on the early success of the spreadsheet solution, the protagonists got promoted or left the company...
The little autonomous Spreadsheet IT departments did not have the professional IT experience, procedures, etc. [overhead] -- so there was no rigorous process to maintain the spreadsheets and train backup personnel...
The spreadsheet solution, became worse than the problem!
ALL TRUE! I Totally agree with every point. And yes, I've seen those little silos of self proclaimed experts get competitive trying to prove that they can do it faster, better and cheaper. And, the fact is, they could usually back up that promise -- Until (as you point out) it all implodes because it wasn't maintainable and there was no backup (either of the data or the personnel)...
But, in this particular instance, it still turned out to be the best solution because (sparing you the detail) it just wasn't a good application for a full blown IT system.
So, we went with the spreadsheets under the supervision of the Controller and, as much as possible, the issues you brought up were discussed and addressed. And, it worked and never blew up (at least not that that little clique of self proclaimed experts ever admitted).
But yes, we were exposed to every single risk that you mentioned. But, knowing that, we were able to be proactive in avoiding them. So, in the end, it wasn't that I did anything truly great -- but rather I was lucky to be working with people who worked together to implement the best overall solution. In a different organization that may not have happened. It probably would not have happened. So I guess I was lucky.
ALL TRUE! I Totally agree with every point. And yes, I've seen those little silos of self proclaimed experts get competitive trying to prove that they can do it faster, better and cheaper. And, the fact is, they could usually back up that promise -- Until (as you point out) it all implodes because it wasn't maintainable and there was no backup (either of the data or the personnel)...
But, in this particular instance, it still turned out to be the best solution because (sparing you the detail) it just wasn't a good application for a full blown IT system.
So, we went with the spreadsheets under the supervision of the Controller and, as much as possible, the issues you brought up were discussed and addressed. And, it worked and never blew up (at least not that that little clique of self proclaimed experts ever admitted).
But yes, we were exposed to every single risk that you mentioned. But, knowing that, we were able to be proactive in avoiding them. So, in the end, it wasn't that I did anything truly great -- but rather I was lucky to be working with people who worked together to implement the best overall solution. In a different organization that may not have happened. It probably would not have happened. So I guess I was lucky.
It sounds as you weren't just lucky... sounds as if you were aware of the potential problems of both options and set up procedures to mitigate the problems of the option you recommended.
It sounds as if Good Enough was the best solution in your case.
In your experience, what is the typical IT months backlog in today's world?
ALL TRUE! I Totally agree with every point. And yes, I've seen those little silos of self proclaimed experts get competitive trying to prove that they can do it faster, better and cheaper. And, the fact is, they could usually back up that promise -- Until (as you point out) it all implodes because it wasn't maintainable and there was no backup (either of the data or the personnel)...
But, in this particular instance, it still turned out to be the best solution because (sparing you the detail) it just wasn't a good application for a full blown IT system.
So, we went with the spreadsheets under the supervision of the Controller and, as much as possible, the issues you brought up were discussed and addressed. And, it worked and never blew up (at least not that that little clique of self proclaimed experts ever admitted).
But yes, we were exposed to every single risk that you mentioned. But, knowing that, we were able to be proactive in avoiding them. So, in the end, it wasn't that I did anything truly great -- but rather I was lucky to be working with people who worked together to implement the best overall solution. In a different organization that may not have happened. It probably would not have happened. So I guess I was lucky.
It sounds as you weren't just lucky... sounds as if you were aware of the potential problems of both options and set up procedures to mitigate the problems of the option you recommended.
It sounds as if Good Enough was the best solution in your case.
In your experience, what is the typical IT months backlog in today's world?
Backlog? I happily have no idea... I am very much retired and, at this point, I am not sure if I could/would step back into that world of total commitment, late night phone calls, weekly business trips and 70 hour work weeks. Actually, I consider myself in recovery from all of that and I'm now focusing on rebuilding my body after battering it with 12 hour work days sitting in front of a computer, fueled with a near continuous stream of coffee, cigarettes and fast food cheeseburgers...
Comments
But, on the other hand, there was luck involved in that I was consistently able to work with people above and below me that worked together as a team with common purpose to do that. I could not have done it without their support -- Or, more correctly: We could not have done it without our support.
The best example I can give is when I was first hired into a start up IT company with the goal of having me lead a team to design, build and support a custom inhouse automated invoicing system. After doing a thorough analysis I gave a presentation to corporate executives where I told them it would be overly expensive to build. And then, they would hate it because it would be expensive to maintain, be cumbersome, and lack the flexibility they needed. And so I recommended instead that they use speadsheets to do the work semi-manually (all the while thinking that I had just analyzed myself out of the job I was hired to perform). To my surprise, the executives bought it. But the Controller hated me for the next 10 years -- until we were bought by another IT firm who had built exactly that! And, even though it was a quality (but expensive) build, it was an albatross for the very reasons I had predicted... The Controller, once he got a taste of it, (grudgingly) finally admitted I had been right!
Am I haughty? No, no more than Steve was. Like me, he was proud of what he did. But his humility drove the process from the knowledge that it was hard work and brutal honesty by he and others that made those products what they were.
(And no, I am not comparing myself to Steve. Just pointing out that we shared some common attributes)
So, did they have an IT department within the company that maintained the spreadsheets?
I have seen implementations where user departments used a spreadsheet solution to get results because the company's IT department had a backlog of 1-2 years to implement a custom automated system...
The user departments became little silos of spreadsheet expertise and evolved into little autonomous Spreadsheet IT departments -- each with their own backlog...
Even worse, based on the early success of the spreadsheet solution, the protagonists got promoted or left the company...
The little autonomous Spreadsheet IT departments did not have the professional IT experience, procedures, etc. [overhead] -- so there was no rigorous process to maintain the spreadsheets and train backup personnel...
The spreadsheet solution, became worse than the problem!
And yes, I've seen those little silos of self proclaimed experts get competitive trying to prove that they can do it faster, better and cheaper. And, the fact is, they could usually back up that promise -- Until (as you point out) it all implodes because it wasn't maintainable and there was no backup (either of the data or the personnel)...
But, in this particular instance, it still turned out to be the best solution because (sparing you the detail) it just wasn't a good application for a full blown IT system.
So, we went with the spreadsheets under the supervision of the Controller and, as much as possible, the issues you brought up were discussed and addressed. And, it worked and never blew up (at least not that that little clique of self proclaimed experts ever admitted).
But yes, we were exposed to every single risk that you mentioned. But, knowing that, we were able to be proactive in avoiding them. So, in the end, it wasn't that I did anything truly great -- but rather I was lucky to be working with people who worked together to implement the best overall solution. In a different organization that may not have happened. It probably would not have happened. So I guess I was lucky.
It sounds as you weren't just lucky... sounds as if you were aware of the potential problems of both options and set up procedures to mitigate the problems of the option you recommended.
It sounds as if Good Enough was the best solution in your case.
In your experience, what is the typical IT months backlog in today's world?
I happily have no idea... I am very much retired and, at this point, I am not sure if I could/would step back into that world of total commitment, late night phone calls, weekly business trips and 70 hour work weeks. Actually, I consider myself in recovery from all of that and I'm now focusing on rebuilding my body after battering it with 12 hour work days sitting in front of a computer, fueled with a near continuous stream of coffee, cigarettes and fast food cheeseburgers...