A common axiom I hear frequently in this industry is "there's no reason to re-invent the wheel". Stop and think about that logic for a second. The first wheel is believed to have been invented around 3500 B.C. Imagine what the world would be like today if every person since then just thought "there's no reason to re-invent the wheel". The wheel has continuously been re-invented and iterated on after its initial invention, and our lifestyles are a much better place for it.
When you face a feature that needs to be implemented, sometimes it is simpler and easier to use an existing solution that already does exactly what you need. Most of the time though I find it much more beneficial, especially in the long term, to either build a new solution from scratch or iterate on an existing open-source solution. Do your research, analyze the problem, and ask questions to figure out which is better for the problem at hand.
Have questions about CASE? Check out the CASE GPT AI assistant.
Greetings, my name is Erik Gassler. I am a software developer with a passion for making workflows more efficient and productive. Throughout my career, I've been lucky enough to work with teams and companies that have given me the freedom to further develop and improve my Continuos Agile Software Engineering practices.
The standards I've developed and refined throughout my career have repeatedly shown that a single developer using these standards and practices can be 5 to 100 times more productive than teams of 5-10 developers using today's popular Agile methodologies like Scrum and Sprint.
I never realized how bad the software industry was at developing software until a few years ago when I transitioned to working at Microsoft.
More often than not, I come across businesses and developers who blindly copy what they perceive to be Industry Standards. However, because nobody truly grasps the frameworks and standards in question--nor understands why they work or how they benefit--Everyone is doing something different that is failing to be productive. People are simply going with their gut feeling instead of solid evidence.
That is why I chose to create this website, which would showcase the standards that I have found to work best in developing high-quality software.
I want to help others improve their software development standards and practices so they can be more efficient and productive while also employing best practices for security, accessibility, and user experiences.
There is an underlying philosophy behind most, if not all my standards and best practices. That is to "keep things simple".
This site will introduce you to the methodologies, principles, and practices I have developed over my career.
I have fifteen years of experience developing software with various companies, and all the views on this website come from my observations. I'm always looking for ways to be more productive and efficient, so I carefully study workflows and processes. When I see something that isn't working well, I try to find a way to improve it. This might involve taking suggestions from other developers or managers, researching methods used by others both in books and online, or developing my own methods.
I am a strong advocate for agile development and continuous delivery of features and updates. However, I have found that certain tenets and tools associated with these terms are often used incorrectly, preventing companies from achieving true agility.
For example, I do not believe that Scrum should be used in a company, organization, or team scope. Many people think of scrum as agile development when it is simply a tool. While I agree with the idea that it can be beneficial for some people in certain scenarios, it does not mean that it is right for everybody or every project. Every company that I have seen claiming to practice Scrum does not practice it in an agile way. Instead, they have structured themselves into imitating waterfall development through miniaturized cycles - mini-waterfalls. They also hold daily status meetings which they refer to as Scrum meetings, missing the fact that Scrum meetings are not intended to be status meetings.
Software development is a continuous learning experience. We should always strive to learn and improve our craft by adapting to new challenges as they come up. And understand that no tool, framework, methodology, or standard is going to be the best practice for every scenario or problem we face.
I am constantly trying to improve the quality of this documentation by adding new information and revising old standbys, but I will only be able to do so much. I hope that you understand that Continuous Agile Software Engineering should always be treated as a a work in progress and use your best judgment to fill in any gaps or make improvements to suite your needs.
A concept we see people chasing all the time is the concept that we need all developers in a company or team to have the same standards and workflows.
This concept is disrupting the simple fact that people are all unique and different. We all think differently, we approach problems differently, and we solve problems in different ways.
No solution or standard is best for everyone. Like time, concepts like readability and organization are relative concepts. What one person finds to be easily readable and well-organized, another may find illegible and cluttered.
As an industry, we need to stop chasing this pipe dream and acknowledge and embrace the fact that we are all different.
Be able to adapt your teams and projects to embrace your developers' strengths and give support for their weaknesses.
Some developers can only be productive when they are given clear, explicit instructions on what to do and how to do it. There is nothing wrong with this. Give them what they need, and they will produce great work.
Other developers may be less productive when given clear, explicit instructions on what to do and how to do it. There is also nothing wrong with this. Give them more abstract problems to solve and don't micromanage their decisions. You'll get better results from them while also freeing up time that would be spent providing them with instructions.
Some developers will perform better using a tool like Scrum to organize and manage their work, while others will find it disruptive and hindering their work.
You may have developers that thrive working in constant collaboration with their team. Talking through problems and solutions to figure out directions to take. Group these types of people.
Other developers may thrive working by themselves, only wanting to collaborate to figure out specific challenges they need help with or helping others when they need specific help. Allow these people to work independently and have the option of excluding themselves from team collaboration meetings.
And additionally, don't demand the same standards, workflows, and methodologies for all of your developers, teams, or projects. Instead, allow freedom for people to use what works best for them, while also having the freedom to share and learn from other developers. This way they can continue learning and growing and adopt newer, better practices at their own pace, while never being forced into a practice or standard that decreases their productivity or the quality of their work, which would in turn reduce their motivation and morale with the team or company.
The CASE methodologies are broken up into twelve tenets, with each tenet containing three core principles.
You can also come chat with us on the Stoic Dreams discord server.