3 ms·

Thing is... a lot of projects seem this way when you're in the thick of it, but towards the end the mess can untangle itself and provide a useful tool/product f

by rquirk 13y ago

Thing is... a lot of projects seem this way when you're in the thick of it, but towards the end the mess can untangle itself and provide a useful tool/product for someone. > Application is unstable and very difficult to use. Could be that there are a couple of "killer bugs", fix them and it might not seem so bad. Difficult to use is also subjective, people get use to stuff. > System is very convoluted, code very hard to understand, very difficult to change. This could be "I don't understand the code, or know how to change it". > Datamodel is too driven by a complex relational database (100+ tables). OK, this one I can't defend :-P > Unclear leadership, the manager responds to every new information with significant change in plans. Well, if the plans are adding new features, these should go to the "nice to have" list. If it's "we need to rewrite this" then that's not good. > Almost no automated tests or unit test. No autowhatnow? :-D I don't think a project is necessarily "headed for failure" just because there are no automated/unit tests. > Heavily depends on other systems, but no integration tests yet. Yet! That's good, there's still time to test this before shipping. > In fact, we actually just inherited this project (along with the mess) around 1-2 month ago from another dev team under the same manager, who have worked on it for a few month. Aha! The root of the problem "I don't feel comfortable with other people's code"?

zenlikethat 13y ago
Interesting take, in fact recently I was working on a project that I was convinced was going to be a huge mess but in the end out clients seemed fairly happy with it, and understanding on inevitable roadbumps. > OK, this one I can't defend :-P I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data?
- rquirk 13y ago
  > I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data? Maybe it's my lack of imagination, but I can't think how you'd create a design with hundreds of tables by hand - it would surely involve generating tables from some other source. For different types of data I'd lean more for a javascripty-style meta-table with key-values, since I bet all that different type of data wouldn't lend itself well to relations.
  - papsosouid 13y ago
    Have you never worked on a reasonable sized application before? 100 tables is entirely ordinary and expected.
tlear 13y ago
Do not understand someone else code, is a valid issue, if the project was development for a few month. Then team got switched around this is a huge RED flag by itself. Big question is why this happened. Staring at a large code base with 1.5month to finish it, no tests, probably zero documentation and manager who used to manage the previous team.. RUN not walk away from this
papsosouid 13y ago
>OK, this one I can't defend :-P What? That is the one thing that stands out as being an obvious "this person has no idea what they are doing" red flag. It doesn't need defended. Having 100 tables is not a problem, in any way. Thinking that having a correct database is bad speaks very poorly for the quality of the developer in question.

by rquirk 13y ago

zenlikethat 13y ago

Interesting take, in fact recently I was working on a project that I was convinced was going to be a huge mess but in the end out clients seemed fairly happy with it, and understanding on inevitable roadbumps. > OK, this one I can't defend :-P I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data?

rquirk 13y ago
> I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data? Maybe it's my lack of imagination, but I can't think how you'd create a design with hundreds of tables by hand - it would surely involve generating tables from some other source. For different types of data I'd lean more for a javascripty-style meta-table with key-values, since I bet all that different type of data wouldn't lend itself well to relations.
- papsosouid 13y ago
  Have you never worked on a reasonable sized application before? 100 tables is entirely ordinary and expected.

tlear 13y ago

Do not understand someone else code, is a valid issue, if the project was development for a few month. Then team got switched around this is a huge RED flag by itself. Big question is why this happened. Staring at a large code base with 1.5month to finish it, no tests, probably zero documentation and manager who used to manage the previous team.. RUN not walk away from this

papsosouid 13y ago

>OK, this one I can't defend :-P What? That is the one thing that stands out as being an obvious "this person has no idea what they are doing" red flag. It doesn't need defended. Having 100 tables is not a problem, in any way. Thinking that having a correct database is bad speaks very poorly for the quality of the developer in question.