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”.

 

[Imb]

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?

No, never persuaded. But I did feel why they were asking something that they could handle, and understandable for them.
Especially older people, or not technical skilled, don't think in normalized data. And thus are not always happy with the way structured programs work.

But this brings me to a different interpretation of your title:
"Have you ever been confronted with building something with a design that others think it is utterly ridiculous?"

In that case: yes!

I must agree, the work I am doing is Access-unconventional: I use in principle unbound forms! And that is quite a statement!
The bounding of form controls to the fields makes form very, very static, apart from the fact that records can be locked.
In the proces of bounding the form "knows" where and how to store the information, but does nothing know about other wishes or constraints of the control as the user wants. For that you can use the BeforeUpdate or AfterUpdate events, but that introduces still more control dependencies.

Now take a 180 degrees turn, starting from the user. What are the properties of this control?
Store these in a metadate table, including the table and the field where the control "belongs to", and create the field in the BE.
Without going directly in the data-database, all is conducted from the FE, including all the controls behaviour. So, it is not necessary to have an in-between form between "user-controls" and table-fields, there is a complete separation. When entering a control on a form, a reference is made to the metadata table, and the control "knows" how to reach the corresponding field for retrieval or storage.
No lookup-tables, no comboboxes, no control classes, no form classes, no dependencies.

It is now possible to generalize all underlying processing, and thus automatically build applications. The form is just a carrier of "to-be-defined-controls", tuned by some code in modules, and the same form can be used for almost anything. Moreover, these form-definitions can be placed in a linked code-library, and shared over all applications.

Finally, because "forms" are completely dynamical, you can present your user "his/her form", not violating
normalization rules, including all wanted flexibilty.

​