Mastering the Fundamentals of Software Development

Six plus months into building devlab and I’m looking back on the genesis of the idea. Three years of discussions between myself and the principal technical architect led to its fruition. Many of those 500 discussions we’ve had off and on over the years relate to the importance of methodologies, frameworks, and models. Technology has never been a barrier. Insufficient mastery of teamwork, communication, and design are the reasons behind project failures. Improving the fundamentals of methodologies, frameworks, and models help avoid this failure.


It might seem farcical to compare a software developer to an athlete in your mind. There are a few parallels, they both do repetitive kinds of work on a schedule, at times need to perform at their highest abilities, and need to work on a team. You might be thinking peak performance looks different than an athlete. That might be true but programming is the implementation of design and ideas and is not the performance. The performance in software development is the day-to-day activities of teamwork. Design exercises, communication, and working on complicated products on a team are as important as the act of “coding”.

Software delivery team fundamentals

Tasks to Complexity You might be wondering how does a hospitality-focused developer platform shape peak performance? The purpose of this white-glove platform is to remove the barriers that waste team members’ time. The Developer skill progression image above reflects how we are solving one aspect of software development. I want software delivery teams I support to improve their fundamentals of working, not waiting on tickets. Standardization and uniformity reduce cognitive load. Teams can spend their mental energy on business problems and not worthless feel-good decisions.

Methodologies, frameworks, and models reduce cognitive load and provide steps to continuous improvement. Methodologies are structures on how to complete work and work together. Frameworks are an agglomeration of tools for building on or solving problems. Models are representations of reality but are not reality. To be successful in a software delivery team you need to know when to leverage these tools and when to throw them away.

When it comes to the coaching of the software developers it doesn’t come down to what hotkeys they use, how their IDE is set up, or how fast they type. The bottleneck for our developers is the thought process of the design of a solution. Does our platform enable our developers to craft API rich experiences for consumers of their APIs? Is the variety of front-end frameworks limiting us from moving to new projects? Do we agree across the business what our fundamental representations of how our business operates in code? Are we wasting time translating models across projects or reaching out for more data? One of the hard parts of software development is that reality changes and our code must change as well to accommodate those changes. The best thing our platform can do is to help get out of the way of developers. This article by Tim Cochran illustrates a low effective environment for software development. In a field dominated by auto-didacts, you might be surprised that training is still essential.


When I first entered software development as a QA I joined a team and missed a Mike Cohn agile training at a marketing company. I was learning the ropes and some ideas of what the team learned at the time but for a while, I was pretty mistaken about what agile is composed of. When I moved on I joined another company their version of agile appeared to be similar but looking back it was not. Then when I joined Veterans United Home Loans, I was a little bewildered how much people kept talking about agile. The company continues to grow and I felt it was a little odd how much agile basics kept being repeated almost to the point of me being sickened. Now four years on I understand. I am adamant about repeating the importance of agile. You need to stress what might seem simple and obvious information to your teams.

The backlog is always negotiable! The acceptance criteria are always negotiable! We can unstart stories. I’ve also learned that I need to communicate using many methods and mediums. People absorb information in different ways better or worse. for some people a graphical model representing the requirements. For others, a video walking through step-by-step on how to achieve something is great. Or a written document in a narrative form sends the message across in the simplest way. I’ve learned as a product person success means doing whatever is necessary to get the job done. Sometimes taking out the trash or picking up drinks. Sometimes standing in for higher-ups. Whatever it takes for success.

Providing Guidance

This is a silly example of when I needed some user interface/user experience help. I reached out to an expert in the business. He gave excellent advice and one thing that at first incensed me, and then I realized it was masterful. He suggested I start with Bootstrap. Boiling down the entirety of web design is inaccurate! Dismissive of the expertise of an entire field! Yet, that’s what I needed to hear to be successful at something I know very little about. If you can take away anything from my experiences take these three things.

  • When asked for advice on improvements, suggest one idea
  • Methodologies, frameworks, and models are a starting point, not the destination
  • Small changes will make a big difference each week