Some background
I am the newest member of a small team of 3 developers. For the past two years I have been working with them on an application the two of them made roughly 5-6 years ago. This application has no documentation and no design or analytical methodology has ever been applied to the development process. The latest medium-scale change to the system dragged on for over a year as a consequence of the convoluted mess that is our current codebase.
As a result of my post-mortem analysis on this change, we are moving towards a full rewrite of the whole application since the market is moving faster than we can extend the system. This time, however, I have urged that we do so methodologically, rather than rush forward. This was met with enthusiasm, though it has since become clear that my coworkers are not experienced in software design on any level.
To the question
I am the only person in my team with any experience in terms of software design, and that experience is purely academical, which means that it will fall on me to do the heavy lifting at least in the beginning, but I am at a loss as to how to approach this in a way that both elevates my team members understanding of how to reason around software while also not breaking my own back in the process. In short, I am looking for any kind of workshop ideas, or learning resources, that I could share with them on topics like GRASP and SOLID, or object oriented design in general, and how to structure such workshops in a productive way.
Edit: clarification and further background
In an attempt to keep the question short, I think I may have neglected some key points in our current situation. The rewrite I mention is more akin to a "refactor into a new platform", spurred on chiefly by being built on and with deprecated technology that doesn't cut the mustard any more in terms of security and performance. The application is a browser-based web application, so we can switch routes in our current solution to point to our new solution with "minimum effort" (Knock on wood) and gradually replace parts of the old with the new a little at a time until it is all new. The change I mentioned above was not the only factor, of course, it was just the final drop in a bucket that has been filling for some time. Originally, the software was used in-house only, but since it fills a niche in the market, we are now selling the solution to customers. The original product owner's workflow does not match the workflow of any of our other customers and their previously hands-on management approach lead to a system where everything is connected to everything else for the sake of shortcuts that now no one can justify or remember why they were built. Before I started working here, issues would bounce between acceptance test and development for weeks because the solution was wildly incorrect. Testing meant and to a large extent still does mean that the support staff pushes buttons and seeing if they get the result they expect. This has bitten us in the rear multiple times, as features that were considered stable and complete years ago fail spectacularly on the smallest deviation from ideal inputs.
This is where I see the real problem. Our development process is not conducive to code of any quality to speak of, and we need to do something to shake up how we work. With a new version on the horizon, I see an opportunity to do just that. I want to introduce methodological software design not as a magic bullet to solve all our problems, but to slow down the pace a bit so that we don't trip over our own feet at every step of the way, produce an understanding not only of the actual requirements on our application but of the application itself, and how its different parts fit together to form a whole. It's not an application full of complicated business logic, it's a large collection of different problem domains which almost never overlap except for interacting with a common core-entity. There is a modular architecture in there which would facilitate development, sales and support, but it's not going to appear on its own, and if we don't do something, we'll end up in the same mess we are now because it is too easy to look at what we have and just do the same thing in a different language.
And this is why I am looking for advice or resources on how I can introduce the rest of the team to software design, at least enough that I can apply what knowledge I have and expect them to understand at least broadly what I am talking about. Especially since we are dividing the project into two phases, one phase which is a small subset of entirely new features, with a new UI and general usability goal, before taking on the task of moving current features into the new system. The first phase will be done all in house, by the three of us, and the second phase will be implemented mostly by external consultants working remotely under our review, with the three of us producing the backlog and design documentation for them as they work. I believe that phase one provides a perfect opportunity for us to cut our teeth on a new development process, provided we can get the ball rolling.
