Comprehensive Software Design Thinking

 Comprehensive Software Design Thinking


Measure twice and cut once is a well-known aphorism in the construction industry. It cautions that one should not rush to execution without being thorough in preparation and planning. In software, and in this era of all things Agile, that principle is still essential. Whether you are working on a prototype, an MVP, a seemingly small feature, or a major release, it is important to take the time to plan before rushing to execution. The benefits of doing so outweigh the costs. In some cases, you’ll avoid running into major issues, and in other cases, by having a complete picture, you’ll simply be better positioned to fine tune the scope of work, choose what is essential and place non-essential tasks on the product backlog.


-Ensure you fully comprehend what is to be built so that you can reliably scope the work

-Ensure that you haven’t overlooked a key element, such as an adverse cyber-security impact or a required database modification

-Ensure that you don’t miss a peripheral impact to the overall system, such as a performance degredation or increased caching costs

-Ensure that you fully capture the User Experience and all UI impacts, so that you don’t find out later that the user experience is worsened or a common workflow is overlooked

-Ensure that all actors and use cases are considered, so that admin or internal users are accommodated


When I’m managing a software project, I keep a checklist handy to ensure that I don’t miss an important impact when introducing a new feature. This checklist is pretty comprehensive, but extremely quick to run through, so it is silly not to use it. Incidentally, not having a checklist just means that someone, somewhere along the product development pipeline is doing it on the fly in their head.


A Sample Checklist (not comprehensive):

-List each system component, including micro-services

-List database components

-data requirements, including sample, test and live data

-testing requirements, test cases, test data

-List of users/actors

-Scalability Impact

-Caching Impact

-Performance Impace

-Front-end Layer

-Mobile Apps

-Websites

-API Layers

-Blogs

-3rd party Integrations

-Security Vulnerability Implications

-UI/UX Interfaces impacted

-List of Major Use Cases

-Deployment impacts, to all environments: testing, staging, production

-Conflicts with ongoing or other development

-Documentation changes

-User permissions/rights/role changes at the application and/or database layer

-OS system configuration, application, user changes


I’d like to reiterate that you can still hold true to the rapid development methodology and even a ‘move fast and break things’ approach. If you take a moment to checklist review any proposed task before jumping into execution, you will have far more confidence in the scope of work and its likelihood of achieving business objectives.








Popular posts from this blog

Blockchain & Decentralized Finance (DeFi) Terms for Beginners

Use this guide to educate yourself or help others better understand Blockchain and Decentralized Finance By Marshall Swatt ( @marshallswatt ) The original whitepaper for Bitcoin, by Satoshi Nakamoto:  https://bitcoin.org/bitcoin.pdf "Layer 1": Networks  - these are the underlying blockchain networks, like Bitcoin, that facilitate transactions, maintain one or more tokens, and facilitate additional functionality such as data storage, computation or customizable behavior. There are literally hundreds - if not thousands - of layer 1 blockchain networks, offering a wide array of different benefits and capabilities, with the aim of targeting a specific market opportunity, to provide competition and spur innovation, for pure experimentation and research, to improve on existing networks, and other strategic business or novel technical differentiation theses. Who knows how this ultimately shakes out, but my bet is that Ethereum is guaranteed to have long-term healthy competition, and
Read more

Software Architecture: Micro-Services and Zero-Trust Systems

Software Architecture: Micro-Services and Zero-Trust Systems When it comes to software development, even with all the tools and methods at our disposal, it is still far too common for teams to jump into development without taking a little time to draft a software architecture plan. Laziness, pressure and inexperience are the most common excuses for this behavior. Any business that takes itself seriously should eliminate that risk of such behavior and incentivize its teams to think before they build. When attempting to architect a software system, you need a methodology to guide you in the process. Otherwise you risk building an ad-hoc solution that later requires a costly refactoring effort. It is all too easy to overlook performance, scalability, security, internationalization. The concept of micro-services can offer a helpful methodology to compartmentalizing software and think in terms of components. Whether you actually build micro-services or not, this way of looking at a software
Read more