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" 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, but it contributes to the larger problem. 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 are no longer necessary or workable. Before I started working here, issues would bounce between acceptance test and development for weeks due to miscommunication. Testing meant, and to a large extent still does mean, that the support staff push buttons and see if they get the expected result. This has been a concern, as features that were considered stable and complete years ago fail on deviation from expected inputs.
This is where I see the real problem. Our development process is not conducive to quality code, 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 solution to all our problems, but to slow down the pace a bit so that we may better understand not only the actual requirements on our application, but of the application itself, and how its different parts fit together to form a whole. It is not an application full of complicated business logic, it is 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 is not going to appear on its own, and if we don't do something, we will face the same problems we always have 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. 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.
