Chapter one Basics
When we set out to do things, we try to find the best way to accomplish them. It’s in our human nature. We want what is best of the best. Same comes when we design software.
It takes patience, understanding, knowledge and a bit of luck to get well designed software to ship. To help you along the road, here are some tips that could make that process run more smooth than ever!
Principles
Have in mind some of these principles and your project will go smoothly. Plan and execute quick and nimble, and your productivity and products will flourish!
Practice the 4 A’s
- Aquire
- Annotate
- Alphatize
- Atune
Aquire: Get a list of requirements at early stages of development. If you adhere to these and get these pinned down earlier in dev stages, the chances for having to iterate over months will vanish.
Annotate often. Create software architectural documents in Google Docs and other authoring software and share them. Make ammends and annotate other’s features and comments to them. Create revisions and list them when there are major changes.
Alpha-tize means to create a basic pre-Alpha and develop the base code and framework for a larger software. Do this in conjunction with other developers and testers and keep your team close to the original requirements to get more done quickly without making too man small error prone changes in Alpha.
Atune your goals, test releases and documentation so other groups or teams are aware of them. Create tests and dev test versions often, maybe even in continual integration with automation like Python, Ansible or other build systems, but verify correctness early on. Develop the tests and tune the test plans for your major releases. Keep all teams and project owners tuned into your efforts often.
Acquire Good SDLC early on and practice it. I know, I said 4 A’s, sorry.
There are plenty of good articles and methods online to study and implement when it comes to software release cycles. But, come up with those that fit you and your team and stick with them to succeed.
Chapter 2 design patterns
Most people would try to look this information up on the internet and recite it from there. Not me. I am going to type this from my own mind and from what I have learned works.
Start with learning what are some software design basics. Learn about the starting spaces of an application. You start with the platform it’s going to run on. What is your intentions? Are you designing an app for windows? Will it need to startup in an exe on a desktop and install to your office internally only? Or, is it a part of a large app for data services that you will eventually sell to customers, packaged as a manager for a cloud system? What is the end software? What is its function and features at the end of the day?
Once you have prototyped it all in your mind, next think about the data, it’s operational flow and lifecycle. Architect these into the end solution from day one. Keep performance in mind. If the software needs to reference data 10,000 times, make sure your data structure and processing core code are streamlined and fast. Start simple and work to complex, not the other way.
Define initial things:
Data Objects
Processing and Control Objects/Variables
Operational flow
When you begin, start with structured, segmented code that is self documenting. Write object oriented, scoped code and classes that self identify with their names and build the meaning into these names and calls.
Atomize class data from very large, monolithic object structure down to smaller ones, and always, firstly, build in a framework for future additions. This allow future enhancements and features to be coded with ease. Document what the new features do, and be as detailed as you can.
Last update: 7/2/2025 Orem, UT.
