How to convince a team of programmers to abandon the old ways?

Question

It is rather a business-oriented programming issue that I cannot figure out how to solve. I work with a team of programmers who have been working with BASIC for over 20 years. I was involved to help write the same software in .NET, only with updates and modern methods. The problem is that I can’t get any of the other three team members (all BASIC programmers, though now .NET) to figure out how to make a relational database. Here is what they will not understand:

We basically have a transaction that tracks client tag information. We need to be able to track current transactions and past transactions. In the old system, a flat file database was used, in which there was one table containing records with the main current client transaction, and another transaction in which there were all previous client transactions along with important monetary information. To prevent redundancy, they overwrite the current transaction with history transactions (the history file was updated first, and then the current one). This is completely irrelevant, since you only need one transaction table, but my manager or any other my second company. Workers cannot understand this. How exactly can I convince them to see the light of day, so that we don’t have to do a ridiculous amount of work and end up hitting the data too often? Thanks for entering!

Answer 1

First, I must admit that this is not entirely clear from your description of what data structures and logic are in existing structures. This implies to me that perhaps you are not explaining your colleagues as well, so one of your priorities should be to understand, both verbally and preferably in writing, as well as charts, the current situation and the proposed replacement. Please consider this an observation rather than any criticism of your question.

Secondly, I really notice that programmers with 20 years of experience do not understand relational databases and transactions. Flat file encoding came out of the mainstream a long time ago - I first processed relational databases in a commercial environment back in 1988, and by the mid-90s they were quite common. What sector and type of product do you work in? It seems to me that you can deal with some kind of built-in or otherwise “unusual” system, in which case you need to make sure that you do not have any communication problems, and you don’t notice a big elephant that was not indicated to you , you would not be the first “consultant” to be brought into a team that was configured in some way without receiving relevant information. However, such archaic stores still exist - one of my current client systems interacts with a file-based system encoded in COBOL, and yes, this is hell for management; -)

Finally, if you are completely confident in your position, and you are faced with a team that will not take your recommendations - and the demo code is a good idea, if you can save time - then you will probably make the decision gracefully and transfer it . In this position, I would try to abstract the problem: is it possible to move databases to stored procedures, for example, so that the code for updating both tables is in SP and can be changed later to go to your schema without changing the application accordingly? Make sure your arguments are well documented and written down, so you can come back to them later if the opportunity arises.

You will not be the first coder who would have to implement a suboptimal solution because of office policies - use it as an educational experience for your personal development in such situations and empathize with the thought that you will pay for additional work. Often the decisive factor in such arguments is not the logic, but the “weight of reputation” that you bring to the table - it looks like you were involved in you, you do not have much leverage with your team, so you may have to work on gaining a reputation, succeeding in realizing what they agree to do before you have a good reputation in the following cases - you need to modify it first!

Answer 2

Sometimes you can’t.

If you read some XP books, they often say that one of your biggest hurdles will convince your team to abandon what they always did.

As a rule, they recommend that people who cannot adapt, go to other projects (or just let them go).

A code review may help in your case. Mandatory code reviews of each line of code are not unheard of.

Answer 3

Once the best argument is an example. I would write a prototype (or a replacement if not too much work). With a case study, it will be easier to see the pros and cons of a relational database.

As an aside, flat databases have their places, since they are much easier to “administer" than a real relational database. Keep an open mind .; -)

Answer 4

I think you may have to give an example - when people see that the “new” way is less work, it will accept them (until you rub your noses into it).

I would also ask if the old design is really causing a problem or just aesthetically annoying. It is important to choose your battles - if the old design does not cause a performance problem or complicates the system, you can leave the old design alone.

Finally, if you leave the old project in place, try to abstract the interface between your new code and the old database, so if you convince your employees to improve the design later, you can abandon the new scheme without having to change anything.

Answer 5

It is difficult to extract the whole mass, except for general disappointment from the original question.

Yes, there are many methods and habits that choose for a long time, which can be useless and even costly in the light of technological changes. Some things that made sense when processing power, memory, and even disk were expensive, might be silly optimization attempts right now. Also, very often people accumulate bad habits and bad programming patterns over time.

You have to be careful.

Sometimes there are good reasons for the things that these old timers do. Unfortunately, they may not even be able to say “why” - if they even know why more.

I see a lot of this kind of frustration when newcomers enter the enterprise software store. This can be bad, even when the environment is a fairly modern technology and tools. If most of your experience is writing small desktops and web applications, then a lot of what you know may be wrong.

Often there are requirements for transaction logging at a level higher than what your DBMS can do. Quite often it is necessary to go beyond the framework of database transaction semantics to ensure the correctness of the time sequence, once and only after updating, resiliancy and non-repudiation.

And this does not even begin to solve the problems associated with the scalability of the enterprise or between enterprises. When you begin to approach half a million complex transactions per day, you will find that RDBMS technology does not allow you. Because relational databases are not designed to handle large transaction volumes, you often have to break the standard paradigms for normalization and updating. Conventional RDBMS locking methods can disrupt scalability no matter how much hardware you choose to solve the problem.

It is easy to discard all this as insecurity or general illegality - even incompetence. But be careful, because this is not always the case.

And by the way: There are other models besides the DBMS, and the alternative to the RDBMS is not necessarily “flat files” - contrary to the experience of most encoders today. There are hierarchical transactional DBMSs that can handle much higher throughput than RDBMSs. IMS , is still very much alive in large IBM stores. Other vendors offer similar software across platforms.

Of course, in a 4-person store, perhaps none of this has.

Answer 6

Sign them up for some decent workouts, and then you, to convince them that there’s a lot more with new technologies (or at least easier!).

But I think the most important thing here is that professional certified trainers first teach them the basics. They will be more impressed that instead of one of their colleagues telling them: "Hey, why not use this?"

Related post here .

Answer 7

In the yr situation, the following cannot apply, but you mention very little technical details, so I thought I would say this ...

Sometimes, if access patterns are very different for current data than for historical data (I am doing this example up, but I say that current data gets accessed 1000 times per second and accesses a small subset of columns and all current data fits less than 1 GB , whereas, say, historical data uses 1000 GB, is available only 100 times a day, and access to all columns),

what your peers do will make sense to optimize performance. By separating the current data (redundantly albiet), you can optimize the indexes and data structures in this table for higher frequency access patterns that you could not do in the history table.

Not everything that is “academic”, or “technically” correct from a purely relational perspective, makes sense when applied in a real practical situation.