6 ms·

Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not try to impose your

Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not try to impose your conclusion on them. Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south. I hope future historians will be astonished that all of us chose to accept such insanity without doing anything to change it. Thought experiment: There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks. The project has been in development for 1.5 months and has 1.5 months to go before the deadline. Their current solution apparently involves relying on a relational database as some kind of programming language or configuration system (100+ tables). There's a good chance that a developer with ambition and talent could singlehandedly deliver a superior solution within a short timeframe. So what stops the developer from executing? Primarily his own (fully justified) fear of negative consequences. But the only reason his fears are justified are because of structural problems in how companies operate today: managers are expected to drive the direction of the project and are given the authority to do so, and the authority to fire anyone who won't go along with the manager's vision. That makes it impossible for a developer to make sweeping changes and be perceived as doing anything but challenging the manager's authority. But it's not about authority. It's about the customer. It's about making good products. Yet the environment is set up so that the developer concludes that it's entirely justified to be afraid; to sit quietly and do nothing. And it's precisely this collective fear that drives this sort of degeneration within companies. There has to be something better. I want to try to build something better. Some new way of thinking about how to build a modern software business. Profit sharing, maybe. It might be possible to set up a company such that it could pay its employees a percentage of the profits. The first employee would get 15%. The next employee would get 7.5%, and the next 3.75%, and so on. Then as the company makes profit, that profit is continually paid out proportionally to each employee. That system has all sorts of flaws, though. One example: an employee should only be getting a percentage of profits while they're at the company. They should be getting their full percentage on day one, and should give up their percentage on the day they leave the company. But I can't think of any mechanism which would actually let a corporation pay out like that. If you tried to pay out profit via dividends, then you'd have to allocate the percentages using stock, and employees don't typically get stock up front on day one -- it takes several years to vest -- and they don't lose it when they leave the company. So profit sharing via dividends wouldn't work. The idea is to provide an incentive to employees for projects to be useful to customers. There's currently no incentive. Employees are generally expected to play the politics/career game in order to secure a safe future for themselves. I guarantee you that if the employees at OP's company had been given some percentage of future profits, then they would currently be revolting and calling out that manager's behavior and incompetence.

PaulHoule 13y ago
"...There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks" These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality. Complex systems tend to have many written and unwritten requirements that aren't captured in their clones. Anyway, I would not look at 100+ relational tables as being a bad practice in and of itself. I've worked on plenty of systems of this complexity, and it's really no problem at all if you're systematic. You need to have a machine-readable data dictionary and you can't be writing all your SQL by hand.
- hobs 13y ago
  Yeah, the 100 table thing threw me as I regularly work in business software with over 1000 tables. The count of tables is less important than organization of them. If you have a clear structure and set of relationships, it is not too difficult to chunk their concerns.
- sillysaurus 13y ago
  These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality. Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be approved, and I did it only after I fully researched and understood the problem space and the future goals of the company. Then I made sure the design took into account all of those future contingencies without being rigorously bound by them, i.e. flexible and not a hindrance when the business goals change in the future -- which they always do. At the most recent company I worked for (a massive corporation) the system is expected to be in production for the next 3 years at a minimum. I did the first 90% of the work in two months, then the other 90% of the work in another month or so. The fourth month was spent primarily on training, documentation, and meetings. Competence exists. The managers are simply given the authority to squander it or to perceive it as a threat and fire them. I was lucky enough to have a manager who was receptive to me overstepping my bounds as a contractor. I made decisions (such as making Redis a core requirement of my design) before asking permission or waiting for approval. I presented a demo of an early version of it to my manager at the end of my first week, and thankfully he was both surprised and happy about it. (40x improvements to the existing infrastructure tend to elicit that reaction.) But most large corporations, and even many small ones, aren't like that at all. You'd be fired for overstepping your boundaries, whether or not you were capable of making a difference to the bottom line. It's up to the manager, and that is a wholly backwards way of running a modern software corporation. For software companies, there has got to be a better way than the existing approach. At the very least, the concept of a "manager" should be divided into two people: a manager and a producer. The producer's role is to drive their project's goals. The manager's role is to ensure that the employees are happy and to deal with roadblocks (such as if an employee needs to purchase a third-party tool). The manager has the authority to fire people; the producer does not. The manager's goal is to look after the team, not the project. And neither of them can tell an employee what to do. The employees are given tasks to complete, not steps to complete, and then trusted to complete that task. The employee is trusted not to accept tasks which he/she feels are too ambitious for the producer's timeline. So the producer can only barter with the employees, not demand from them. I know of a massive videogame company (not Valve) which operates that way, and it's the reason they're currently the industry leader in their genre even though they've grown exponentially as a company over the past four years, both in employee count and customer count. So it absolutely worked for them, and I'm willing to bet that it would work in a lot of software companies. I want to prove that it works.

PaulHoule 13y ago

"...There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks" These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality. Complex systems tend to have many written and unwritten requirements that aren't captured in their clones. Anyway, I would not look at 100+ relational tables as being a bad practice in and of itself. I've worked on plenty of systems of this complexity, and it's really no problem at all if you're systematic. You need to have a machine-readable data dictionary and you can't be writing all your SQL by hand.

hobs 13y ago
Yeah, the 100 table thing threw me as I regularly work in business software with over 1000 tables. The count of tables is less important than organization of them. If you have a clear structure and set of relationships, it is not too difficult to chunk their concerns.
sillysaurus 13y ago
These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality. Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be approved, and I did it only after I fully researched and understood the problem space and the future goals of the company. Then I made sure the design took into account all of those future contingencies without being rigorously bound by them, i.e. flexible and not a hindrance when the business goals change in the future -- which they always do. At the most recent company I worked for (a massive corporation) the system is expected to be in production for the next 3 years at a minimum. I did the first 90% of the work in two months, then the other 90% of the work in another month or so. The fourth month was spent primarily on training, documentation, and meetings. Competence exists. The managers are simply given the authority to squander it or to perceive it as a threat and fire them. I was lucky enough to have a manager who was receptive to me overstepping my bounds as a contractor. I made decisions (such as making Redis a core requirement of my design) before asking permission or waiting for approval. I presented a demo of an early version of it to my manager at the end of my first week, and thankfully he was both surprised and happy about it. (40x improvements to the existing infrastructure tend to elicit that reaction.) But most large corporations, and even many small ones, aren't like that at all. You'd be fired for overstepping your boundaries, whether or not you were capable of making a difference to the bottom line. It's up to the manager, and that is a wholly backwards way of running a modern software corporation. For software companies, there has got to be a better way than the existing approach. At the very least, the concept of a "manager" should be divided into two people: a manager and a producer. The producer's role is to drive their project's goals. The manager's role is to ensure that the employees are happy and to deal with roadblocks (such as if an employee needs to purchase a third-party tool). The manager has the authority to fire people; the producer does not. The manager's goal is to look after the team, not the project. And neither of them can tell an employee what to do. The employees are given tasks to complete, not steps to complete, and then trusted to complete that task. The employee is trusted not to accept tasks which he/she feels are too ambitious for the producer's timeline. So the producer can only barter with the employees, not demand from them. I know of a massive videogame company (not Valve) which operates that way, and it's the reason they're currently the industry leader in their genre even though they've grown exponentially as a company over the past four years, both in employee count and customer count. So it absolutely worked for them, and I'm willing to bet that it would work in a lot of software companies. I want to prove that it works.