June 8, 2024 at 12:00 am
Comments posted to this topic are about the item Is Perfect Software Attainable?
June 8, 2024 at 9:37 am
As the term 'perfect' is poorly defined in the context of software, one person's 'perfect' is another person's 'not bad'.
I don't remember ever using software that I didn't think could be improved – even when written by me!
Aiming to exceed customer expectations is the way to go, IMO. Leave perfection to philosophers.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
June 8, 2024 at 11:28 am
I'm been working with and creating software since 1969 and have never seen 'perfect'. While some might have been close, the inevitable cycle is (1) OK, (2) really good, (3) 'good idea', (4) bad decision, (5) new release, (6) rinse and repeat.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
June 8, 2024 at 11:59 am
Cool! A debate about the dialectics of software 🙂 This is actually a throwback to a rather old philosophical question, subject of much debate between people such as Hegel and Marx.
Hegel argued that perfection, or in the topic under debate, total knowledge (omni-science), was possible by increasing knowledge incrementally through thesis, anti-thesis and synthesis (or in software terms: the current software, your next sprint, and the resulting new version of the software). This would ultimately lead to perfection, which is equal to the Divine, as you would be omniscient.
Marx argued that since there is no God, you can't become Divine, therefore omniscience isn't possible. You will incrementally approach it but never reach it (it's an asymptotic approach to a limit, basically).
How lovely to see that debate translated into software terms. When people say philosophy has little value in the real world, they are blisfully unaware of ontologies, semantics (especially in data) and debates like this.
June 8, 2024 at 2:39 pm
My biggest problem with all of this is that people keep poo-pooing the words "perfect" and "perfection". That, in itself, isn't a problem but what people think after all the "training" they've had from the world's largest bandwagon of poo-pooers has driven by is that since "perfection isn't possible" and "multiple release retries are ok", the concept and acceptable levels of "good enough" has taken a trip to the toilette.
This has been further exacerbated by "schedule". It's amazing to me that "progress" is frequently measured by how many deployments of fixes there are instead of valuing single deployments that worked correctly the first time and continue to to do so without modification.
What's really bad is it seems that "Above all else, cause no harm" has come to mean little in software. What's especially frightening is that AI has mastered those very human DILLIGAF attributes in many areas AND a lot of people don't care because they're used to such human failures. It has even produced some truly piss poor and dangerous code that it has rendered under the seriously untrue claim of "Here's how Jeff Moden would do it".
People have forgotten how to "Do it right the first time".
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2024 at 4:49 pm
Perfection is a goal and it can be very far away. Incremental shorter goals can be used to get to "perfection" in more manageable chunks.
I have seen software that was written by developers that had great vision and many features that could be easily added to the framework already made. Unfortunately, the architect can leave and those remaining do not have the same skills or vision. It was sad to see what COULD have been... but others were not able to continue on... everything went in another direction... not necessarily worse, just mostly different.
I think the journey to "perfection" has many paths... but it should be shared by others on the team... or a lot of time can be spent changing directions without making progress toward a goal.
The ability to envision the road ahead is quite the gift... to be able to build a framework that allows for future features to be easily added.
My vision is too short-sighted, I have to keep reworking things to add something I didn't see coming. I keep hoping for more experience to help me make better decisions about directions that should be prepared for... and less gold-plating dead ends that will never be used.
My journey continues... I am hoping to get better and wiser. Accomplishing that 10 years of growth vs. 10 single repeated years. 😉
June 9, 2024 at 2:01 pm
Very interesting topic. Early in my career I naively thought that writing a perfect software system was possible. But that, as you say Louis, in only for the most trivial of cases ("Hello World!")
I am unfortunate enough to work for an organization which still strongly adheres to waterfall methodology, although there are some who are challenging that. My boss, recently retired, was one of those proponents of waterfall. He also thought he was a good UI/UX designer. Unfortunately, his designs were all weird. In 5 years, we started 8 applications all based upon his UI/UX design which required the user to memory the database structure. He totally disregarded the users process, and only focused upon designing UIs which presented each table for CRUD operations in its own window. The users either memorized the database schema or printed it out. Can you imagine Amazon publishing their database schema so customers could memorize it or print it out, while trying to purchase anything on Amazon? They'd never have become the ecommerce powerhouse that they are, if they'd done that. Of course, all of those 8 applications have failed, because none of them were what the users wanted. However, each of them was well documented and defined, in good waterfall fashion.
Kindest Regards, Rod Connect with me on LinkedIn.
June 11, 2024 at 9:17 pm
I appreciate Phil Parkin's comment regarding perfect being in the eye of the beholder. I recently re-designed a screen for our staff and had one user review it. The user did not like the re-design and had good reasons. So, I created a second re-design and yay, the user loved the second redesign. Then I showed the second re-design to a second user, and she hated it. So, I showed the first alternative design to that second user, and she loved that first design--also for good reasons. Neither of the designs is perfect, but each design is best for the needs of a subset of users.
I do not like the word 'perfect', though I'm not sure why. I think my resistance is in part because I don't believe it is desirable to spend the time to get to an unlikely attainable perfection, if nothing else, for the reason I listed in the first paragraph.
Instead, I have always sought to reach the level of 'ideal.' I want to make ideal software for my users. Why do I think that 'ideal' is a better concept? I just looked up the definition of 'ideal' and many of the definitions include the concept of perfection. So, perhaps there isn't a usable difference between the two concepts.
However, the way I look at it: perfect is "without blemish or defect." I don't need to make software that never has a blemish or defect from the user's perspective. I need to make software that make's my user's hearts soar: the software needs to meet the business needs, help them be efficient and fast, make it hard to create an error, guides them on what to do next, be a joy to use with few clicks, etc, etc, etc. Even if there are little blemishes (maybe they don't like the color of the screen or think that a box needs to be bigger etc) and thus the software isn't perfect for every user, I aim to make software that is ideal in that it meets all the important ideals.
I recently visited the office after a couple years of working from home straight. I did the rounds and introduced myself to a large set of users for the first time. Upon learning who I am, strangers rushed to give me a hug, they lit up with a giant smile, and one even offered chocolate. When asked if they had anything they wished to ask for, so many people shook their heads, "no" and told me how much the software helped them do their jobs and that was all they could think of at that moment.
What's my point? : My software is NOT perfect. By no means. I'm 100% sure that there are blemishes in the software that users would change, and I'll hear about those blemishes over time. However, the users' overall relationship with the software is one of contentment. I feel like I've given them ideal software. Instead of aiming for a nebulous "perfect", my suggestion is to come up with a set of ideals like the ones I listed above and aim to meet those ideals.
June 18, 2024 at 10:49 am
The point made about perception of perfection from the users of our work is important. People may have to live with the product of our labours for many years. If your work helps them achieve their objectives, in a way they would struggle to do without it, then the cost and process will be forgotten if not forgiven.
Then there is our personal pride to consider too. Do you want to stare at your work with pride or shamed for eternity? There is work that I was proud of when I produced it, but today I would do it better. It does however do what the client wants, when the client wants it to do so, therefore any "improvements" would be for my benefit, not theirs.
If you are in a senior position you have to hold yourself to a high standard even though there may be many demotivational factors at play. Working under someone who has "given up" is corrosive.
Thinking back, having worked on both agile and waterfall projects I really don't think it makes a lot of difference to the quality of the eventual product. It is hard to tell because success has many fathers and disaster is always an orphan. There is a vested interest in stakeholders and managers proclaiming our work as a success. You have to do appalling badly for it to be declared a failure.
June 18, 2024 at 3:54 pm
Ah... I found the word I was looking for...
Lookup the term "enshittification". It's a term that was coined by XXXXXXXXXX in 2022 and became the "word of the year" for 2023.
Here's a couple of articles that I thought were a great combination of "fun to read" and "excellent examples"...
https://thewalrus.ca/the-scourge-of-self-checkout/
https://medium.com/@andymacdroo/stopping-enshittification-ed4998cb8253
I also include people that conduct interviews for senior data positions that require the use of SQL and yet require no demonstratable proof that they actually know even fundamental syntax. For example, people seem to rail against such interview questions as "What is the syntax and required parameters for the SUBSTRING() function in SQL"? They also become combative for questions like the "Fizz Buzz" problem or how to get a sum of zero for dates that aren't present in the data. Their claim is "they can look it up".
Yeah... you're trying to hire a Senior Database Developer specifically for SQL Server... please DO find one that doesn't have the SUBSTRING() syntax and parameter usage memorized and let me know how that works out for you. This is almost as bad as a Senior DBA for SQL Server not knowing what the 3 Recovery Models are and not being able to describe the particulars.
People say they "hire for attitude"... me too... If they have the "right attitude", they will have studied the knowledge areas and practiced the skills to actually do the job I'm trying to hire someone for.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply