Lovely write up here! In fact I think I could relate to at least 6 out of 10! Especially the first one. In my own experience I found that there are users who are just plain biased and have a dislike for your application/solution before you even penned one line of code! So when it is deployed, there is a seemingly endless comparison of the old system and the new that will always end in..."I can't work if the application does not work like the old one!" They have a change aversion. They do not like new things!
Secondly, when you have clients, end users and stake holders that cannot agree on how the software should function, you can have a software project that is easily stalled and delayed unnecessarily. This is my take on this!
Discussion on:
View:
Show:
These guys use the stuff to do their jobs, it can help or it can hinder. They rarely get any real say in the end product, usually designed by managers and beancounter ffs.
Go talk to them, get some concrete problems. That's when you find out that your new form (the only bit they care about), has the fields on it in the wrong order, or inhouse jargon is stuffed up. Things that only people on the job know, and that really matter to them, and would probably take about ten minutes to fix and make them really happy. Do some heuristics or cognitive walk throughs and then validate them. If you wrote something they don't like, that's your (or possibly management's) error not theirs
The other thing to bear in mind, is the guys right at the bottom of the food chain entering data into systems, need to get something out of them. Put your sales hat on tell them why they should like it. Do not even mention some new shiny kit or tech, or other arcane crap. Instead of navigating through 15 different menus, click this button, that's what they want to hear.
Go talk to them, get some concrete problems. That's when you find out that your new form (the only bit they care about), has the fields on it in the wrong order, or inhouse jargon is stuffed up. Things that only people on the job know, and that really matter to them, and would probably take about ten minutes to fix and make them really happy. Do some heuristics or cognitive walk throughs and then validate them. If you wrote something they don't like, that's your (or possibly management's) error not theirs
The other thing to bear in mind, is the guys right at the bottom of the food chain entering data into systems, need to get something out of them. Put your sales hat on tell them why they should like it. Do not even mention some new shiny kit or tech, or other arcane crap. Instead of navigating through 15 different menus, click this button, that's what they want to hear.
These are all good points, including tooblessedtofail's. I have run into each and everyone of them over the last 10 years. But what is the solution???? Strict adherence to a SDLC/Design methodology? The last quality "system" to come down the pipeline. Usually a repackaged/renamed iteration of some quality system from a bygone era and sold as a panacea to all our IT project woes. Then only to become part of the problem. It comes back to one everlasting tenet. Leadership!!! Despite all the tools, methods, gimmicks, systems, programming languages, new technology, legacy success it's the kind of leadership, collectively and individually, that follows clear definition in design and manages expectations for that design. Maintain the vision, direction and sharing that with all in the circle of development. You can wrap whatever "system" around it you want. But stick to the goal and vision and then share the design.....my 2 cents...borne of all the same frustrations.
I think I agree that there's always got to be someone who is driving the quality and they have to have comprehensive oversight and influence on decision making to make it work;
but Agile is a clear step forward over waterfall. I'm not talking about some highly specific definition of Agile but just the whole idea of minimal viable product with iterative review and release.
but Agile is a clear step forward over waterfall. I'm not talking about some highly specific definition of Agile but just the whole idea of minimal viable product with iterative review and release.
Sometimes it won't be, though that will be rare. There are other methodologies than those two though, and they'll fit some projects far better.
My biggest problem with Agile, is a bunch of panacea merchants running around saying this is new (it isn't), this is radical (it isn't) this is THE answer (not just no but hell no)
Do yourself a favour and qualify your statements, otherwise some might think you are as competent as they are...
My biggest problem with Agile, is a bunch of panacea merchants running around saying this is new (it isn't), this is radical (it isn't) this is THE answer (not just no but hell no)
Do yourself a favour and qualify your statements, otherwise some might think you are as competent as they are...
PS. Also critical share with all, the "10 commandments of Ego-less programming".This one really works
I generally prototype with basic html.
It shows the users all the buttons/functionality we'll have to talk about and usually having a screen will prompt them to ask questions and provide more ideas for functions. Get it all out on the table up front and then we can discard and have the original printouts with buttons/functions marked off for phase II or later. I'll even mock up a dashboard to ensure the developers are paying attention to the right chokepoints.
Of course, I also verify that the backend functions _can_ work but usually that's as simple as doing hello world stuff for myself if it is some new technology.
It shows the users all the buttons/functionality we'll have to talk about and usually having a screen will prompt them to ask questions and provide more ideas for functions. Get it all out on the table up front and then we can discard and have the original printouts with buttons/functions marked off for phase II or later. I'll even mock up a dashboard to ensure the developers are paying attention to the right chokepoints.
Of course, I also verify that the backend functions _can_ work but usually that's as simple as doing hello world stuff for myself if it is some new technology.
Fine if all your code has a user-interface. The IT world is much broader (and deeper) than some believe.
Re: 7: Promising before planning
In an email, Allan P. Clapp reminded me of one of my worst nightmares: the salesperson who says Yes to a customer before talking to the developers.
Not only do they say "Yes", they also promise a delivery date before even telling the development team about the "feature". If the developers say 2 months, the sales person or management says they have to have it in half or less time and schedule it accordingly. When it is not delivered "on time" but actually takes the time that the developers stated, the developers are blamed for delivering it "late".
In an email, Allan P. Clapp reminded me of one of my worst nightmares: the salesperson who says Yes to a customer before talking to the developers.
Not only do they say "Yes", they also promise a delivery date before even telling the development team about the "feature". If the developers say 2 months, the sales person or management says they have to have it in half or less time and schedule it accordingly. When it is not delivered "on time" but actually takes the time that the developers stated, the developers are blamed for delivering it "late".
You make a prototype for the typical purpose of a prototype, that is showing to our internal users to get feedback and learn stuff to actually build the real thing. But then someone above you sells the prototype to a customer.
Yeah the prototype can handle 3 or 4 users at once and can give a reasonable demo and the user interface looks done but they then try to get their whole company using it and well it's a prototype.
And the version number at the bottom of every screen even says "Version 0.1a."
Yeah this is going to be a _fun_ year.
Yeah the prototype can handle 3 or 4 users at once and can give a reasonable demo and the user interface looks done but they then try to get their whole company using it and well it's a prototype.
And the version number at the bottom of every screen even says "Version 0.1a."
Yeah this is going to be a _fun_ year.
If you are doing front end, don't do a back. If a back, don't do a front. Aside from stopping fools selling it, the effort that goes into one should be targetted at it's pupose. If it's really a version 0, then it's not a prototype. I got bit once now I deliberately and obviously cripple them in the name of efficiency.
4 and 5 collide. The guy who keeps wasting time in meetings nit picking about the colour or the shape while everyone rolls their eyes may have useful input but he needs to learn how to filter it. He might get excluded. Strict rules about gathering requirements may help.
8 and 9 sometimes contend as well. You don't like what's available but no-one has got anything better. Can your team do a better job?
8 and 9 sometimes contend as well. You don't like what's available but no-one has got anything better. Can your team do a better job?
Oh, I worked for a couple of months under a project that was heavily defined by #7. #6 also applied. The project died.
It is easier to say No when you are working as an independent developer. The difficulty however sets in when the company you work for asks for the development. saying no to your boss may make you seem arrogant or hiding your incompetence
It seems that the error list is related to the system engineers's point of view. I agree with that if i punt on the shoes of the people who have to make the software.
But if you think from the point of view of the user, then you should take into acount that he will became into a "customer".
An all the marketing, bussiness, etc. theoretic guys agreed that "the customer is always right".
So you have to think as a user (customer) and realize that the "system" have to adapt to you, and not that you have to adapt to the system.
If the system doesn't fill the user needs, then it is simply wrong and therefore does not serve, that is it.
Of course, I agree with you that the user always is changing his requirements, or that the user doesn??t know exactly what he want, but since the beginning of system engineering it had been like that, isn't it?
And in order to deal with it appears amazing theories for requirement's capture, complex systems designs, rational unified approach, the newest agile methods, and so on.
So it would be nice if the software engineers realize that many of the mistakes listed are consequence of an inappropiate requirements capture... and therefore known what to do
Regards,
Elias
But if you think from the point of view of the user, then you should take into acount that he will became into a "customer".
An all the marketing, bussiness, etc. theoretic guys agreed that "the customer is always right".
So you have to think as a user (customer) and realize that the "system" have to adapt to you, and not that you have to adapt to the system.
If the system doesn't fill the user needs, then it is simply wrong and therefore does not serve, that is it.
Of course, I agree with you that the user always is changing his requirements, or that the user doesn??t know exactly what he want, but since the beginning of system engineering it had been like that, isn't it?
And in order to deal with it appears amazing theories for requirement's capture, complex systems designs, rational unified approach, the newest agile methods, and so on.
So it would be nice if the software engineers realize that many of the mistakes listed are consequence of an inappropiate requirements capture... and therefore known what to do
Regards,
Elias
Looked more like a PM's point of view to me. Aside from inconsistent requirements, there's nothing a software engineer can do with an invalid one. They don't even know it is invalid. They are engineering to the requirement they were given.
A software engineers view of why projects fail.
Change is a given
In order to successfully and efficiently cope with change quality engineering is a must.
In business quality = good enough.
Well it wasn't was it!
Again...
HtHs
A software engineers view of why projects fail.
Change is a given
In order to successfully and efficiently cope with change quality engineering is a must.
In business quality = good enough.
Well it wasn't was it!
Again...
HtHs
"What happens with the fact: "the customer is always right"?"
At my very first job, our training had a quote that's stuck with me my whole life:
"The customer is not always right, but a customer is always a customer."
The customer is NOT always right. If they knew everything they needed to a T, and they knew it *accurately*, then software projects would have a much lower failure rate.
But, just as importantly, the customer has major gaps in their knowledge that limit their ability to be right. For example, a customer may have an ideal process for handling a piece of paperwork, and they demand that the program 100% replicate the paperwork. That's almost always a provably poor approach. It usually WORKS, but it loses most of the "point" of turning it into software in the first place. For example, replacing the long list of checkboxes with a long radio button option group may be a 1-to-1 translation, but a combo box + autocomplete is much more likely to make it easy for the users.
The trick is to act with the customer's best interests in mind, and there is a way to show them what can/will work better without being rude or nasty about it.
J.Ja
At my very first job, our training had a quote that's stuck with me my whole life:
"The customer is not always right, but a customer is always a customer."
The customer is NOT always right. If they knew everything they needed to a T, and they knew it *accurately*, then software projects would have a much lower failure rate.
But, just as importantly, the customer has major gaps in their knowledge that limit their ability to be right. For example, a customer may have an ideal process for handling a piece of paperwork, and they demand that the program 100% replicate the paperwork. That's almost always a provably poor approach. It usually WORKS, but it loses most of the "point" of turning it into software in the first place. For example, replacing the long list of checkboxes with a long radio button option group may be a 1-to-1 translation, but a combo box + autocomplete is much more likely to make it easy for the users.
The trick is to act with the customer's best interests in mind, and there is a way to show them what can/will work better without being rude or nasty about it.
J.Ja
The customer is (effectively) paying the developers to do work. That work (should) include analysis and design. If you can get that right it should be just a matter of expressing the customer's requirements correctly, so that the developers can do the design.
If the customer starts designing the software, including the interface design, then why does he need to pay the developers to do it? This indicates weak preparation from sales.
If the customer starts designing the software, including the interface design, then why does he need to pay the developers to do it? This indicates weak preparation from sales.
No matter what analysis is done at the start of any non-trivial project, it will be wrong / incomplete at the end of it.
If you can get analysis and design right.
You can't.
Even if a developer and customer had the resources to do so. In any non-trivial project, they will change. Even discounting any external factors (e.g. OS and back office changes), and given that there were no misunderstandings or omissions, and that your people (and possobly theirs) didn't have a learning curve, and that resources stayed available and their environment was static, the mere existence of the new software will change the perception of requirement once it gets seen.
That doesn't even consider the basic business process of not spending significant effort investigating the needs so they can be costed, with no expectation of actually getting the job!
The situation you are describing has only ever existed in the classroom, never happened in real life, probably never will. It's perpetuating the fallacy that it could is the most significant aspect of project failure. Wrong expectation from Day Zero...
If you can get analysis and design right.
You can't.
Even if a developer and customer had the resources to do so. In any non-trivial project, they will change. Even discounting any external factors (e.g. OS and back office changes), and given that there were no misunderstandings or omissions, and that your people (and possobly theirs) didn't have a learning curve, and that resources stayed available and their environment was static, the mere existence of the new software will change the perception of requirement once it gets seen.
That doesn't even consider the basic business process of not spending significant effort investigating the needs so they can be costed, with no expectation of actually getting the job!
The situation you are describing has only ever existed in the classroom, never happened in real life, probably never will. It's perpetuating the fallacy that it could is the most significant aspect of project failure. Wrong expectation from Day Zero...
Let us not forget those wanting the new system to not have any clear idea of just what they want. How can IT develop a system, when what the new system is supposed to do hasn't or can't be defined?
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
