Software design is one of the most important skills a software engineer should have. But what is software design exactly? If you search for a definition you find something like this:

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view. Source: Wikipedia

So, a developer has to design based on a requirement the solution or in other words the source code. There are a lot of decisions to make, for example where to put which logic.

Who is interested in software design?

For the customer the design of the code isn’t important. For him the existence of a feature and its performance are much more important. In other words design isn’t part of a specification (functional or non-functional requirements).
Also the project manager or a team leader might not be interested in software design. For them the productivity and speed of the developers are much more important. And the customer satisfaction is even more important.
So, who is/should actually interested in software design? The developer and his boss. Software design is about having a plan and a structured solution. It is important to implement the right thing in the right way (effectiveness, efficiency). But it means also, that the source code becomes maintainable, readable and extendable. All this capabilities are important when you have to read or touch existing code. And it is about money too: If the existing code is maintainable, then a change could be done much faster and cheaper.

Full stack frameworks

A lot of companies try to simplify the software developing process by introducing a full stack framework. A full stack framework is a framework from an UI layer to a data access layer. The reason of doing this is to make some important decisions just once upfront of any new application. Some of those decisions are the number of layers, the testability or the location of the extension points.
When a developer uses a full stack framework, he has to live with the software architecture of this framework. The framework dictates him where he has to put which logic or where he has some liberties.

But such a framework does help not very experienced developers to produce big or complex applications. And there is another point: If you have to code very little, you do normally no big design upfront, you just code (with or without TDD). But if you know you have to build some bigger application, then you do for sure a design. And there is a problem with full stack frameworks: They do a lot for you and you have to code just a little for a big application: Now the developer might think "I have to do such little of code and the frameworks define where I have to place the code, so there is no need to design".

This rigidity of a full stack framework can lead to developers who stop asking themselves, how a good design might look like because they are "trained" to believe that the guidelines of the framework are correct and complete. In other words, they become code monkeys. So, after a while you can obverse that a lot of anti patterns appear:

• Spaghetti code
• God object
• Shotgun surgery
• Primitive obsession
• Feature envy
• Anemic domain model
• Bad names for classes or methods
• No unit tests
• and so on…

Prevent the kill of the skills

So, are full stack frameworks an excuse when you lost your design skills? No. You can produce also bad code without any framework and you can produce very good code with a full stack framework. Just ask yourself those questions before you write code (the list isn’t complete):

• What business problem do I have to solve?
• Where do I place which responsibility?
• How could I test the code?
• What of the new functionality has to be reusable?
• What should be extendable (YAGNI…)?

Conclusion

A matured full stack framework is very powerful because it increases the productivity and the speed of the developers.
But a full stack framework can be dangerous for young or not very experienced software developers: It is very easy and comfortable to create applications but it is also easy to place the code in the wrong class or forget to make a proper design.
A full stack frameworks can act like a catalyst to create bad code because it is much easier but is never the reason why the developers don’t design their code.

How can you prevent such non-designed code? Pair programming is one of the best ways how to do it: One experienced software engineer, who acts like a mentor, and another software developer.
Code reviews are useful, but they are not always a funny thing for both sides: The developer has already "done" his job and the reviewer has to criticize the result. So, there is a lot of potential of frustration on both sides.
Another way is to follow the boy scout rule: Always leave the code cleaner than you found it.

But the most important thing is, don’t stop designing when you will or have to use a full stack framework. A full stack framework doesn’t substitute any skills of developers, it makes them maybe more productive.