CEOs, CIOs, CTOs, and You: Software Engineering practices and strategies commonly floated around but rarely or difficult to put in practice
Dear CEO's CIO's, CTO's and other Engineering Leaders, here are some Software Engineering practices and strategies that are floated around in boardrooms, strategic planning meetings, status and reporting meetings but rarely or for one reason or another are difficult to put in practice:
A clear vision or plan for the digital product or service: You'll evangelize or often hear from your leadership/investors how important it is to have a clear idea of what the digital product or service (mobile/desktop app, website, etc) is supposed to do and how it will be used, as well as a plan for how it will be developed and maintained. Engineers love to build or break toward a vision they equally believe in or simply explained to and understood as the driver for everything they set out to do. However, this is often overlooked and instead engineers are expected to read/listen/understand the vision from a handed out/published manuscript or worse lost in translation or sometimes just dissipates as it's communicated hierarchically from the vision bearer downstream to the individual contributors.?
A dedicated software engineering team: You will hear and perhaps even charged with relaying to your stakeholders and subordinates the importance of having a dedicated software engineering team responsible for the design, development, and maintenance of the software. This is usually challenged by a conflict between corporate growth ladders and the engineering team's strengths/ambitions. A common example is when an engineer just wants to focus on engineering but the organization wants them to double in people management or the other way round, an engineer wants shift towards people management within engineering but the organization wants them to focus on engineering or move to a different department. So yeah, you will have a "dedicated" engineering team but is it really... dedicated?
Proper development process: A well-defined development process that includes activities such as requirements gathering, design, implementation, testing, and deployment. Most pitches, digital strategy plans, expectations from leadership and in some cases, something an engineering team will want to have in place but because of suboptimal communication channels and ineffective approval processes makes it next to impossible. Here are some examples of such activities you may have heard of or read about commonly bucketed under DevOps: version control to collaborate on and track changes to the codebase,?automated tests to catch bugs and regressions early in the development process, code Reviews, establishing and following coding standards to improve maintainability and readability of the codebase, managing dependencies (external libraries and frameworks) to avoid conflicts and ensure stability of the digital product, handling errors and and exceptions in a graceful manner, continuous integration to automate the build and testing process, documenting code (not the kind written and shelved or that bloats code files, hehe), keeping the code base clean and organized, etc.
Paying attention to scalability: Designing a digital product that can handle a growing user base and workload. This usually defeated by lack thereof a well defined vision/plan for the product or in most cases having a predominantly one-way communication channel. Examples may include "throwing" the vision/requirements over-the-fence to the engineering team and wait for the "finished" product to be thrown back, lack of transparency among stakeholders sometimes due to fear of losing authority or influence or role held, not hearing out a point of view of an engineering individual contributor during ideation or requirements gathering.
领英推荐
Adequately testing the digital product or service: It's important to thoroughly test the software to ensure that it is reliable and works as intended. Common pitfalls occur when architects and UX designers aren't listened to or the end-customer's/user's experience and ease of use ins't prioritized. Common signs of this may include the scope of testing limited to a certain number of devices, browsers, user/audience types etc. You can't satisfy all users but remember, your users aren't all users and if you think otherwise, then you should perhaps spend sometime to figure out who your users are.
A plan for maintaining and updating the digital product or service: Updates and maintenance may include but not limited to fixing bugs and adding new features. Common examples of this can include bloated codebases because it's easier/faster to create a new function/class/module versus reusing existing ones, content added directly in code files (a content change equals a business logic code change) , hard-coded configurations in classes/business logic code files, focussing on new features versus listening to and acting on engineering retrospectives after a recent delivery of a feature/update, focussing on a given technology/tech stack versus a desired product outcome or processes that make the engineering machine go.
Investing in training and development: It's important to invest in training and development to ensure that your software engineering team has the skills and knowledge they need to be successful. This is usually blinded by accolades like degrees, PHDs, certifications, etc. In most cases, these give an individual or a team a voice or a sense of authority in a specific discipline/platform/ or simply a marketing play but doesn't necessarily equate to being trained/skillset development and prepared/set to thrive - unfortunately and understandably so, the goal often is to pass an exam. An organization may do better with sponsored internal and external hackathons. Engineers love to build and break digital things (software/hardware) NOT acquiring glittery accreditations.?
I challenge you and everyone else to test your organization by asking a question about any or all of the examples above - and hopefully by understanding what is and how it is happening, you'll work your way towards a healthy engineering life ;). Most of the examples above are either outrightly ignored or postponed or not thought of/put into consideration and as a result, most organizations' CapEx and OpEx skyrocket through the roof without correlated outcomes. In some cases may lose great and essential partners, teams, and individual contributors only to retain those who say what they want or like to hear instead of what is actually happening and how it's happening. ?