masudio - tech

Building a system means meeting a set of requirements dictated by the customer.  But the customer isn't always going to translate what they want into engineering terms.  Even if you say please, they might not even know how.  If they ask for an online ordering system, they probably won't specify that it needs to be available 24/7 and auditable for tax purposes.  Yet these aspects could mean the difference between project success and failure.  Those unsaid aspects are called anything from 'nonfunctional requirements' to 'Architectural Characteristics'. In their book 'Fundamentals of Software Architecture', Ford and Richards define Architectural Characteristics to have 3 criteria: Specifies a nondomain design consideration Let's dive into these bullets to better understand them. Aspects of Architectural Characteristics Specifies a nondomain design consideration If you're building an ordering system, then order numbers, customers, items and prices ar

As the discipline of software engineering matures, few things remain constant.  A few years ago, a large portion of the community thought that TDD was always the best methodology to use - after all, you move faster by being thorough and preventing bugs.  Nowadays it's clear that unit tests do not ensure a successful project - when you're A/B testing new features or products and you're not even sure if your code will be around 3 months from now, it's better to churn out production code and test it in prod.  You can clean up the mess later, if the business value makes it worth it. But despite the pace of change in software engineering , in software architecture  there exist a set of 'laws' which don't change over time and which apply to all architectural endeavors.  I'd like to talk about 2 of them in this post as they are important ideas to keep in the back of your mind as your skills grow past coding, past design and into architecture. Laws of Software A

You're on a team, undoubtedly.  You have been tasked with solving a customer problem and you have a design ready and waiting for review.  One team member reviewed an early version and asked for some tweaks, but after an iteration they agreed it was the optimal path forward.  You open it up to a wider audience for further review.  But then another team member pipes up... "This design doesn't work - it's just not possible with our current setup" Well, damn!  What do you want me to do?  Do I need to cycle through every team member and get them to give their feedback, iterate and incorporate it and then present it to everyone?  Even if I do that, by the time I get around the group, someone will disagree with the design again! Calm down, breathe - this is what it feels like to learn.  And what you've just experienced is what I like to call the 'Hard' version of Consensus. Every team is different in how they deal with this consensus problem, but if the input

Whether it's about raising a small child or directing a full grown engineer towards her next promotion, mentoring requires a great deal of patience, honesty and self-awareness.  One wrong step and you could trigger a shame spiral.  Or just as bad, you could push your mentee to leave the team for a place with better career and/or learning opportunities.  There are clear rules of engagement to follow, but once you've mastered those, doing it right becomes an art more than a science, so bring your creative energies in order to drive excellence. A common next step after becoming a competent contributor on a software team is to start helping others onboard.  When a new teammate joins, having a mentor can accelerate progress by showing them the next steps in their career path rather than letting them hack it out on their own. But being successful as a mentor can mean many things - the KPIs for mentoring are not as clear as technical projects.  You need to have the trust of your manag