March 11, 2018 at 10:53 am
Comments posted to this topic are about the item Our Greatest Strength, Our Greatest Weakness
March 12, 2018 at 3:48 am
The example with an apple clearly illustrates some major problems which dominate the industry.
The teams have been given a task to draw an object named "an apple".
At some stage they've run out of appropriate ideas, and turned to drawings representing totally different objects but having no relevance to the original object, except for similar naming.
Effectively, the team which did such a substitution, failed the task.
But in this environment people care more about new ideas, creativity, smart ways to overcome problems than about fulfilling the given orders.
So, the trick was accepted.
The subject substitution opened the flood gates, new ideas are pouring out, the teams are expanding horizons, everybody is having fun, except... the actual task which is long forgotten.
This is pretty much how it's going with too many IT projects.
When facing a difficulty "creative teams" do not dig deeper to find an appropriate solution.
They go creative. They do whatever they know how to do, and then invent a way to substitute the original requirements with whatever they've managed to create.
Being pressed to choose between accepting a solution which is not quite what was requested and having no solution at all, customers usually bend and agree to compromise, convincing themselves that was the best the current state of technology can offer.
Which is totally not true.
The biggest problem here is - the right solution has no chance to surface.
It's always takes more time to work out a proper solution than mock it up with something stolen from internet. And "business" never appreciates spending more time on anything.
Therefore proper engineers are being washed out from the industry and get replaced with "effective managers".
And with all the available computing power the new systems can hardly match accuracy and effectiveness of older ones. Which explains why there are so many COBOL based systems still in operation around the world.
_____________
Code for TallyGenerator
March 12, 2018 at 6:38 am
Whenpresented with a new idea for the way in which databases should be managed,DBAs will be quick to spot weaknesses in the idea and threats that the ideaposes to the task of ensuring appropriate availability.
I would suggest that the exact opposite could be true as well. There are many things I've read that immediately strike me as an improvement over the methods I'd be currently using. Striped backups comes immediately to mind. Of course I subjected it to testing. But it was a fairly short development time to getting that into production, significantly reducing both our backup and restore time. But agreed that skepticism is a good approach to many things.
March 12, 2018 at 8:08 am
Sergiy - Monday, March 12, 2018 3:48 AMThe example with an apple clearly illustrates some major problems which dominate the industry.The teams have been given a task to draw an object named "an apple".At some stage they've run out of appropriate ideas, and turned to drawings representing totally different objects but having no relevance to the original object, except for similar naming.
I think you have to be careful what you choose to read into the example. The exercise was about problem solving and trying not to impose an entirely artificial constraint that was neither wanted or specified by the instigator.
The problem of development teams shoe-horning cool, but irrelevant, features into software has always been with us but has been constrained by hardware. Office 97 had all sorts of Easter eggs in it. There have been variations on Star Trek games on mini and mainframe computers long before home computers, let alone PCs were invented.
I have not noticed customers being overly flexible in their requirements. I have noticed them shopping around until they find someone unwise enough to give them the estimate they want to hear for the work they don't have the budget for. I have also experienced the thing where there is never time to do it right but always time to do it over.
March 13, 2018 at 5:16 am
That's the thing.
A constraint not specified - does not mean not meant.
Instigator gets like arrested: "everything you say may be used against you in court".
You've got to right your requirements similar to EULA from MS or Apple, or, better, both of them combined.
Otherwise the creative team will find their way around and you'll end up with a granny instead of a fruit.
And 3 years into the project - the the job of the PM from the side of the instigator is very much doomed no matter what action he/she takes in this situation.
Unless he/she is also creative enough to convince the board that the granny was actually what they needed from the very beginning.
_____________
Code for TallyGenerator
March 13, 2018 at 10:11 am
David.Poole - Monday, March 12, 2018 8:08 AMThe exercise was about problem solving and trying not to impose an entirely artificial constraint that was neither wanted or specified by the instigator.
That's the thing.
A constraint not specified - does not mean not meant.
Instigator gets like arrested: "everything you say may be used against you in court".
Hang on, you are saying that teams will incorrectly invent their own solutions and go off piste but also that a constraint not specified does not mean it isn't meant thereby requiring creative teams to put creative interpretations on requirements. Sounds as if we are damned if we do and damned if we don't.
It feels as if there are two extremes here. On one hand, don't move until all requirements are nailed down. That will take a long time, so much so that by the time the software is eventually delivered the market has moved on. The business has just taken delivery of what they needed 2+ years ago and the original stakeholders are either not with the business anymore or working in different positions. This isn't isolated to software development. In the UK HS1 wasted billions to deliver a system that was obsolete before it was delivered due to changing market conditions.
On the other hand to get something before hell freezes over allow a looser interpretation of requirements but understand that this will require the stakeholders to be actively engaged to make course corrections throughout the development process. You'd never build a safety critical system like this but there are plenty of cases where this works fine.
Where ever on the spectrum a particular project lies the only solution is to maintain dialogue with the stakeholders. If you are going to make assumptions then confirm them with the stakeholder.
March 13, 2018 at 6:48 pm
The business has just taken delivery of what they needed 2+ years ago and the original stakeholders are either not with the business anymore or working in different positions. This isn't isolated to software development. In the UK HS1 wasted billions to deliver a system that was obsolete before it was delivered due to changing market conditions.
The billions would be wasted anyway, no matter when the system would be delivered.
If a new system becomes obsolete only because market conditions change 2 years later - it barely worth the cost of electricity wasted on its production.
It's like Windows which requires updates when a country changes it's day light saving settings.
Putting the settings (data by the definition) into a code is plain stupid, lowest standards of development.
For some reason they are able to synchronise system clock with online time services, but it's too much for them to do the same about DLS dates.
Sadly, this kind of lousy solutions define the standards of development in the industry.
Hardcoding data has become a mainstream approach.
_____________
Code for TallyGenerator
March 15, 2018 at 9:15 pm
The problem is, many of us hinder innovation with constraints, rules, and overall, realism. If you always take the approach that creativity will ultimately lead to a unfinished or unwanted product or service that ultimately doesn't amount to much, then you're no different than the hypochondriac who won't leave the house in fear of catching a disease.
I actually wrote an article talking about just that for this site, but have never submitted it. I too feel that a lot of the realism hinders great ideas that lead companies to great success. That's because like myself, so many of us are caught on all the critical details of an idea. Like if it can scale, if it's secure, how much money will it cost, what technologies will we use, and so forth and so forth. Eventually, you're just finding ways to dismiss something rather than create something.
The idea that creativity is going to ignore all rules and dwindle into a waste of time is a sign that you really don't have much faith in your team. Many of the creatives I've worked with over the years are fully understanding of the game and do not go off that beaten path. They are thinking about what is possible and not possible, but not thinking about all the obstacles in their way because ultimately, no one will come out there house nor take risks if the analyze something down to the grain.
It's a balance and good creative people wield that balance like a double-edge sword. Bad ones end up stabbing themselves in the foot and costing the company thousands if not millions of dollars in wasted time and effort.
March 16, 2018 at 4:44 am
I see what you're saying, and I totally agree wiht it, well, according to my understanding.
I don't know how far did you go in your unpublished article, but if you'd followed the logic deep enough into the cave, you should have come to a conclusion that the main killer of creativity is Agile Development model.
The direction the product development to take, design decisions, priorities, everything else what "makes up" the product - is decided on product owner level.
Dev team can only get creative on how to do what they've been told to do, but they have no say on what has to be done.
There is simply no space for engineers in this model.
That must be why we don't see any innovations coming from well established companies.
Even from the biggest innvators.
Can you name anything from Google with its "most creative office environment" since Google Maps? They've closed every groundbreaking project they've started, except for self-driving car. It's still to be closed, because the whole idea is very "manager driven" one, there is no engineering in it.
Any one else?
Tesla? It's 180 years old design, and if not subsidies and political presure it would not have a chance of surviving, just like back then.
All IT inventions came from garages. Nothing new comes from multi-storey offices.
_____________
Code for TallyGenerator
March 16, 2018 at 5:23 am
Google Dremel. They are also quite active in developing artificial intelligence.
March 16, 2018 at 7:24 am
Dremel?
When some 30 years ago I needed to get a scientific paper which was not present in the local library, my request was submitted to an upper level node of the librarian system, then probaly it was gone more levels up, where the correct reference was found in an appropriate index, and my request went downstairs until the pepper was fetched and passed to me.
Well, because the request was passed via human conversations over telephone lines, and the paper had to be physically delivered to me, it took several days to complete it.
Dremel uses much faster means, but the principals of a distributed data system are not very different from what was in place tens and hundreds years ago.
AI?
It's not their innovation.
iRobot was published on 1950.
Deep Blue was created in 1960-s.
And it's not only Google who "work on it".
It's not much of innovation, just enhancing of existing technologies.
And it's pretty much obvious that semiconductors would never be able to provide sufficient computing power for sustainable AI devices. Just because of the technology limitations.
Innovation will happen when we'll learn how to create and program bio-processors.
But, I'm afraid, North Korea is well ahead of us in the science of producing well trained organic machines.
_____________
Code for TallyGenerator
March 16, 2018 at 8:43 am
Sergiy - Friday, March 16, 2018 4:44 AMI see what you're saying, and I totally agree wiht it, well, according to my understanding.I don't know how far did you go in your unpublished article, but if you'd followed the logic deep enough into the cave, you should have come to a conclusion that the main killer of creativity is Agile Development model.
The direction the product development to take, design decisions, priorities, everything else what "makes up" the product - is decided on product owner level.
Dev team can only get creative on how to do what they've been told to do, but they have no say on what has to be done.
There is simply no space for engineers in this model.That must be why we don't see any innovations coming from well established companies.
Even from the biggest innvators.
Can you name anything from Google with its "most creative office environment" since Google Maps? They've closed every groundbreaking project they've started, except for self-driving car. It's still to be closed, because the whole idea is very "manager driven" one, there is no engineering in it.
Any one else?
Tesla? It's 180 years old design, and if not subsidies and political presure it would not have a chance of surviving, just like back then.All IT inventions came from garages. Nothing new comes from multi-storey offices.
I work with Google pretty exclusively and would say that's not true. In their case, which is not like most of ours, they have enough money to dedicate people to new and innovative things. On my front, we have to do it as the side job because it's too much overhead, not enough revenue. This is likely the main reason why most multi-storey offices don't do this. It's not because of everything else you mentioned, it's just tied to overhead and not making any money while in that mode of innovation. It's the same as most R&D departments and struggling to have them as well continue to fund them.
That being said, there are a lot of of older projects that have been in the works for many years. Google for example likely has a huge amount of projects that have been ongoing for many years that likely will never see the light of day. Then one day, a new members comes onboard and does something crazy with it or has evolved it to something else and now it's in the making years later. Time is not a good measurement of innovation. You are not innovative simply because it got done fast or it was thought of within the past year. You are innovative when you take something and make it better than what's on the market currently regardless of how long it took you.
March 16, 2018 at 9:37 pm
Innovation is not putting a stronge and faster horse in front of a cart.
Innovation is making a cart to move with no horse at all.
_____________
Code for TallyGenerator
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply