Have you ever been persuaded into building something with a design you knew was utterly ridiculous? (3 Viewers)

[BlueSpruce]

My neighbor who owns a machine shop wants me to upgrade an A2003 app I built for his Dad back in 2006. This was the first Access app I ever built. I haven't touched this app in 15 years. The app works, but I wasn't experienced when I built it, so I will have to refactor lots of code, and get rid of forms like "CashCustomers" ... Yeah, I used to let stakeholders talk me into doing ridiculous requests, like "I wan't a separate form for cash customers". Have you ever been persuaded into building something you knew was utterly ridiculous?

 

[CJ_London]

Been asked - yes, pursuaded - no

Last one a couple of years ago was for a theatre company - an employee had built it using only macros and no documentation. And data wasn’t properly normalised. It handled show bookings and some elements of production and staffing rotas. They wanted to license it out to other theatres. It looked good but was difficult to use.

I said no, doubly so when they told me their budget

 

[BlueSpruce]

Been asked - yes, pursuaded - no

Last one a couple of years ago was for a theatre company - an employee had built it using only macros and no documentation. And data wasn’t properly normalised. It handled show bookings and some elements of production and staffing rotas. They wanted to license it out to other theatres. It looked good but was difficult to use.

I said no, doubly so when they told me their budget

Well, in my case, the then owner said if I didn't want to build it his way he would find someone else. I should've refused and walked away, but instead I said okay, I will build it your way, but later on you're going to realize it was a mistake and you will have to spend more money to make it right. The app stayed unchanged for 15 years until the owner recently passed away and now his Son wants me to migrate the app to A365 and properly redesign it.

 

[dalski]

Life is short, do what you want I think. But credit to you, it mustn't be that bad for 15 years of use & so happy that don't want to greatly deviate.

 

[tvanstiphout]

It's a great time to think about new features. Often as a beginner we can present the data, but are not yet thinking much about what to do with it.
For example, are there alerts about quotes that are past due? Orders that are stuck in the process? Can quotes be copied from a template or a previous quote?
Is there excellent data range validation preventing illogical data?
Can customer-facing reports and emails be redesigned with modern font and layout?

 

[BlueSpruce]

it mustn't be that bad for 15 years of use & so happy that don't want to greatly deviate.

It was/is still bad when you have individual forms, reports, and queries dedicated to specific customer types, date ranges, etc.

I knew so and told the deceased stakeholder the reasons why his design was a bad idea, but he insisted I do it his way, because that's how he was doing it in Excel, instead of me standing my ground.

However, I did properly organize and normalize the data because I was not going to build upon a design that propagates redundant data that you have to edit in multiple places.

 

[BlueSpruce]

It's a great time to think about new features. Often as a beginner we can present the data, but are not yet thinking much about what to do with it.
For example, are there alerts about quotes that are past due? Orders that are stuck in the process? Can quotes be copied from a template or a previous quote?
Is there excellent data range validation preventing illogical data?
Can customer-facing reports and emails be redesigned with modern font and layout?

Yes, but first I need to migrate the app and data to accdb, consolidate the redundant forms, reports, queries, and then talk about new features, such as the good suggestions you offered, which I appreciate.

 

[tvanstiphout]

You may also want to consider SQL Server for the BE. Opens up new capabilities, in addition to a more stable and secure BE.

 

[DHookom]

I had an internal customer who designed the fields for me and stated there would always only be two steps in a process so there is no need to normalize. I actually built the application with the proper structure under the hood. After a few months the customer asked what it would take to add more steps. I complained and set it would take days. So, I spent a few days answering questions in Access forums and changed a value in a setup table (taking one minute) and redistributed the app.

 

[BlueSpruce]

I had an internal customer who designed the fields for me and stated there would always only be two steps in a process so there is no need to normalize.

When designing and developing applications, I usually ignore when users say the words "always" and "never".

How many of you avoid creating and using lookup tables, and hardcode values in your vba code when there's only a handful of values?

 

[DHookom]

I had two manufacturing clients at the same time and was creating similar production reports. One client was basically averaging averages or something similar that overstated production which over paid bonuses. I was called into a meeting to explain my findings with the production manager (hired me and got the bonus) and the CFO. I gave the CFO a simple example with three production shifts (6 numbers). He took his calculator to another room for a few minutes. When he came back, he said I was correct. The production supervisor fired me.

A couple years later, I was hired full-time by the other manufacturing company.

 

[BlueSpruce]

He took his calculator to another room for a few minutes. When he came back, he said I was correct. The production supervisor fired me.

Did he fire you because they wanted to avoid paying bonuses even though the production goals where reached, or exceeded?

 

[DHookom]

The calculations the production supervisor wanted me to use were wrong creating higher bonuses. I’m not sure why I was let go, if it was because I found his error or I found his error .

I also avoid using yes/no fields since the future holds lots of “maybes”.