Episode 1:  Is AI coming for your job?

The post The Rage Cage appeared first on SD Times.

Software development engineers in test (SDETs) have historically relied on coded test automation as the go-to approach for quality assurance. However, coded test automation calls for extensive coding that’s resource-intensive and challenging to maintain. Although it’s based on free, open-source frameworks, coded test automation requires skilled labor that’s scarce and costly — constraints that hamstring overburdened tech teams. 

Fortunately, not all testing requires coded automation. New advancements in test automation are emerging, and codeless platforms present a key opportunity to streamline software testing.

Coded automation not the only option 

Coded test automation still plays an important role in scenarios like unit testing and component-level testing. But the development arena has changed in the last 20 years, underscoring the fact that coded test automation isn’t an optimal approach to quality assurance for certain use cases — like functional testing.

Coded test automation requires skilled SDETs or software developers to not only write hundreds of lines of code, but also maintain them. That’s increasingly difficult to accomplish with engineers stretched thin and employers facing ongoing talent shortages. As a result, many development teams lack the resources to maintain copious amounts of code once an application is deployed. Supporting code for coded test automation is also expensive, especially if the test framework requires regular updates or modifications.

It’s clear that new testing approaches are needed to maintain software quality and keep pace with technological advancements. And codeless test automation is gaining momentum — fast. 

Revolutionize testing with codeless automation

Codeless automated testing platforms are now available in the commercial marketplace, eliminating the need to write code for automated tests. With these tools, quality assurance (QA) professionals who lack coding skills can develop automated tests alongside SDETs and developers.

Some developers may hesitate to lean on codeless automation. After all, many developers have spent the lion’s share of their careers writing lines of code. But coded test automation isn’t going away — it’s just becoming one of several approaches developers can turn to. In fact, coded automation remains critical in many testing scenarios. 

However, for functional testing, end-to-end testing, data validation, and regression testing, codeless platforms offer a streamlined approach for both user interface (UI) and application programming interface (API) testing that can cut costs and reduce time-to-market.

Consider the benefits that codeless automation can provide:

• Reduced reliance on technical expertise: Codeless testing platforms enable developers to shift testing responsibilities to QA teams, who can focus solely on testing rather than coding and debugging. Codeless platforms also help free up developers’ time and empower them to focus on new technologies and complex software development.
• Accelerated development cycles: Codeless platforms enable QA teams to use pre-built and visual components to develop automated tests, which is a much faster process than writing net-new code. This enables testers to create more test cases in a fraction of the time, which increases test coverage and results in higher quality software. An added bonus? Shorter development cycles also reduce costs.
• Easier maintenance: Codeless testing eliminates the need for programming skills that are typically required to maintain and update coded test suites. This makes maintenance faster and easier when an application changes. Some codeless automation platforms even have self-healing capabilities that enable the testing tool to automatically fix test scripts or test cases when a test fails or the software changes.

There’s always a learning curve when adopting a new approach. But the barrier to entry is low and the rewards are high when it comes to deploying codeless test automation tools. In the current no- and low-code era, the swift pace of innovation demands agile and efficient workflows.

Consider all the factors when determining whether codeless automated testing is right for a specific use case, from resource availability to the category of testing required. But when you discover codeless is the right fit for a use case, your entire team can test faster with greater efficiency and coverage — ultimately reducing time-to-market for new products while maintaining product quality.

The post In the low-code era, codeless testing tools deliver the efficiency and profitability coded test automation can’t appeared first on SD Times.

But not all open source is created equal. There are a number of open source imposters out there, and companies should know how to identify them to avoid getting locked in to restrictive licenses that are masquerading as “open.”

What is “fake” open source?

Fake—or captive—open source can be defined as software that is released under a license that is not truly open. In order to be considered legitimate open source, licenses must be approved under the Open Source Initiative (OSI), which ensures the software can be freely used, modified, and shared.

One example of captive open source is Mongo’s move from a GNU Affero General Public License (AGPL) to a Server Side Public License (SSPL), which is not OSI-approved and poses significant disadvantages to the user. Similarly, Cockroach moved from a recognized open source license (Apache) to a Business Source License (BSL) which is also not recognized by OSI.

These types of software are marketed as open source because the code can be inspected and contributions are possible. But the license is held by a single company, and the degree of freedom regarding what can be done with the code is miniscule compared to a true open-source project.

When companies opt to use captive open-source software like the examples above, they become locked in to one vendor. This is risky because that vendor can change its license cost at any time, choose which features users get access to (and at what price), and disappear at any time should the company go under.

Another major downside of fake open source? Since these projects are captive to one company, there is little to no community support. For an enterprise that has adopted and is betting on that software, it’ll be difficult to find talent because contributors are limited. True open source like Linux or PostgreSQL (also known as Postgres) is a talent magnet because it revolves around a robust community of contributors and is completely open to inspection and influence. The last Postgres version, for example, had over 140 companies contributing. If users want to see a feature added, they can go ahead and propose it to the community.

Developers love innovation: They want to move fast and be at the center of where breakthroughs and change are happening—and open source is that place. Unlike captive projects, true open source is independent of any one vendor, so if for instance a database vendor that uses Postgres were to go belly up tomorrow, Postgres would continue on unaffected.

Companies stand to gain a lot from open source: The ability to innovate faster, a larger talent pool, community support and contributions, lower costs, and no risk of vendor lock-in. It’s imperative that companies learn the signs of captive open source projects so they don’t waste their time and resources on software that doesn’t give them the flexibility and benefits they need.

How to spot fake open source: A checklist

Recognizing fake open source can be tricky, but by staying vigilant and examining the following items when vetting software, companies can avoid getting locked in to captive projects.

1. Is the software license OSI-certified? One of the easiest ways to determine whether an open-source project is legitimate is to look at its license. If it doesn’t meet OSI standards, reconsider or proceed with caution.

2. Is the project community driven? Choose software that is backed by a robust community versus driven by a single company. Do your due diligence here: There are even Postgres look-alikes out there that are years behind Postgres innovation because—you guessed it—they’re driven by a single company.
3. What’s in the project’s release notes? There should be many—we’re talking dozens—of contributing companies mentioned. This indicates a vibrant community behind the project. Look at which companies and developers are contributing to the project: Do you know of them? If so, do you believe in them? You’d better, because you’re betting your company’s future on it. And when in doubt, always go with the major open-source project and don’t take a chance on a fringe project.
4. What’s the rate of innovation? How often are new releases and features coming out? Regular updates are a good indicator of an innovative project that is constantly improving. For example, Postgres releases major versions annually with around 180 features, in addition to quarterly minor releases that contain many small improvements and fixes. 

Open source has transformed the world of software development and unlocked new opportunities. By knowing how to identify captive open-source projects, companies can ensure they’re investing in software that is a safe bet and will propel them forward, not slow them down.

The post Beware of fake open source appeared first on SD Times.

We all know the critical role software developers have played as the driving force beyond today’s connected collaboration capabilities. But I think that role will only expand and become even more foundational, including in areas that were just pipe dreams a couple of years ago. 

And no, I’m not talking about video conferencing. I’m talking about changing the way we connect – about code that can remotely control physical instruments thousands of miles away, new ways to shop or transact real estate, and tools for remote work collaboration that build real bonds between colleagues. 

As head of Developer Relations, empowering developers to create and build is close to my heart. At my day job, I advocate for the developer community to our product and engineering teams, making sure our product roadmap remains relentlessly end-user driven. This requires me to keep a close pulse on the developer community. 

I’ve been mulling over the question of what new capabilities people will be developing this year. Here are a few thoughts on what we might see software developers building.

Unify communications

Technology is becoming more core to the way people work across every industry, from online banking to telehealth. This year, companies across all industries will work to unify their communications, and software developers will rise to the challenge of creating hyper-specific tools for different industries. 

This will require developers to hone in on understanding and dissecting the problems of their industry partners to propel unified communications efforts. Root cause analysis of industry problems will prove fertile ground for creative, out-of-the-box solutions. We’re seeing harbingers of this wave of development in the video-enabled headsets beginning to connect manufacturing supervisors with workers on the ground, or the drones ferrying vaccines to remote portions of Ghana to increase accessibility to preventative healthcare. Developers, coming in with a systematic approach and logical lens, will be well-suited to create impactful solutions for traditionally analog fields. 

Reduce latency and eliminate downtime 

With that growth in specialized unified communications will come urgency in reducing friction in connected devices. As more workstreams begin to rely on UCaaS technology, the effects of latency and downtime multiply. As everyone has personally experienced, low latency serves as a barrier to retention, incentivizing customers to turn away from a site or give up on trying to make a new gadget work. With companies zeroing in on customer retention as a primary focus given the macroeconomic climate, improvements in latency can make a difference in the bottom line. 

Minimizing roundtrip latency also opens up a world of real-time remote applications, like remote surgery, remote vehicle control, and jitter-free virtual reality. Any application requiring real-time, precise controls depends on low latency, so developers working on such products will be well suited to structure their networks and systems for lower latency. 

With some level of latency unavoidable, as well as users on low bandwidth connections, another management strategy involves researching the key pieces of the user experience and prioritizing those in the user interface. Making use of artificial intelligence and machine learning to adjust the quality of less-important areas of your experience means that users can continue using the tool on suboptimal connections, rather than simply losing access. 

Similarly, downtime can lead to disruption for users. Effective deployment strategies, clear mitigation strategies, and increased test coverage are all proven ways to reduce downtime, improving that all-important end user experience. 

Executives push return to work, employees vote with their feet 

It is crystal clear that hybrid work and distributed workforce strategies are here to stay. If the past two years have taught us anything, it is that establishing clear and continuous communications pathways are critical to success in hybrid work environments. 

This looks like software that works on any device, including mobile, and from any location. With hybrid work trending across companies, and variations in preferred unified communications as a service (UCaaS) providers, interoperability as a competitive edge will be sharper than ever. Companies want to avoid vendor lock-in when they purchase hardware, while tools that allow employees to work with external contacts as well as internal ones reduce friction and increase productivity. 

Developers will have an opportunity to reassure executives fretting about a lack of in-person collaboration, while preserving flexibility for employees to work in the location they find most productive. This will look like enhanced virtual workplaces, next-generation conference room displays, and granular presence controls. 

It all comes down to developers 

Without the tireless work of software developers, the products and solutions we love and use on a daily basis would not have come to fruition. As we embark on a new year, it will be critical for companies to enable software developers to work through today’s industry-specific issues, strengthen the connected devices proliferating in offices and home workspaces, and build for a flexible workforce. This enablement will provide much greater value than any single platform or solution alone. 

The post It all comes down to developers appeared first on SD Times.

No longer is the goal of digital transformation to become digitally native, but instead to drive real, tangible value for the business. Charting a clear path towards that value and executing on it is the differentiator between companies that maximize their strategy and the ones that embrace digital transformation just because everyone else is.

VALUE CREATION

The pace of change in the digital world is dizzying, and it’s easy to get caught-up rubbernecking the competition to spot the latest trends. Digital enthusiasts move in the same circles, read the same articles, and attend the same industry trade shows hyping the hottest tech. The result can be a Frankenstein monster of a digital strategy, cobbled-together tech that might not actually be valuable for their business. The fact is, every organization’s digital transformation is unique, and its success or failure depends on its own specific level of optimization.

At its most basic, digital transformation is a combination of two things – digitization, and optimization. Digitization has been around for a while, and just means digitizing information or making data available in a digital format. Optimization (also referred to as “digitalization”) is more process-focused, and involves using those digital technologies to operate systems more efficiently. A company’s ability to marry digitization with optimization will determine the value of their transformation. 

TECH TALK

Real change occurs by listening, not talking. Oftentimes, CIOs, CDOs and CTOs get swept up in the excitement of a transformation and simply pass down edicts that the company is “going digital” without first determining the strategy or creating KPIs that can properly measure impact. The result? Conflicting plans, varying timelines, and splintered focus. (And a lot of wasted time and money.)

Instead, a digital transformation needs to start by defining business goals and expectations across the leadership team and aligning those goals and expectations with department heads to ensure their vision matches reality. From there, rather than attempt to change an entire organization at once, it’s best to view a digital transformation in layers – what are the areas of importance, how do they stack up against each other, and how can you condense operational needs across departments?

Imagine you’re the CIO of a large consumer packaged goods brand with approximately 50,000 employees across 40+ departments offering hundreds of products to millions of customers. Your technology ecosystem would be a mess of legacy mainframes, aging document storage systems, disparate processes, overloaded IT teams, off-the-shelf systems with low user adoption, and an unstable suite of customer-facing digital channels. How do you encapsulate all of this onto a whiteboard and create a digital transformation roadmap? 

This is where layers factor in. Trying to find tactical solutions to each of these individual issues would lead to silos, multiple bespoke systems, and fragmented processes. By grouping common issues into layers though, you’ll develop a much more manageable, strategic framework.

LAYERS & PHASES

There are six layers to any digital transformation, each condensing key focus areas:

Data – How do you store and retrieve data securely? How do you scale? How do you ensure data integrity and avoid redundancy/duplication?

Application – How do you apply data to run your day-to-day business operations? How do you democratize data access by providing a centralized abstraction and distribution layer?

Process – How do you streamline your business processes?

Experience – How do your internal (employees) and external customers interact with the processes and systems? (UI/UX)

Collaboration – How do cross-functional teams collaborate more effectively to get work done faster? 

Intelligence – How do you derive insights from data and apply intelligence into the work that you do? 

Each layer must go through its own distinct phases of digitization and optimization to result in a successful (and holistic) transformation. How a company defines their own transformation depends on multiple factors unique to the organization, including budget, available resources, and the capacity for innovation over time. This is what makes true transformation a never-ending journey, the same way customer satisfaction is a never-ending pursuit. 

PLAYING THE LONG GAME

Those looking to embark on their own digital transformation journey should be prepared for the realities of working without a finish line. It’s a process of continuous learning, but one that will ultimately create a more cohesive, efficient, and modern operation. By using the layers and phases of a digital transformation as a framework, CIOs, CDOs and CTOs can build a system that works across their entire organization and truly adds long-term value.

The post The Layers and Phases of Effective Digital Transformations appeared first on SD Times.

The answer is as important as ever in today’s digital economy. High-performing organizations empower developers with tools, training and resources to do high-quality work, with security top of mind. This results in the ability to build secure applications quickly that consistently meet expectations and mitigate risk.

As we see too often, though, many organizations struggle to create a positive environment for developers. We see these results in the notoriously high job turnover statistics for developers who quickly move from employer to employer from burnout.

There are fundamental challenges that business leaders must address to improve software development, in particular a developer’s ability to contribute to software security. Doing so can further engage developers in the security process and contribute to the larger security maturity of the organization. 

Let’s look more at developer enablement and what organizations can do to make an impact.

Create an Environment for Developers to Thrive

Organizations must first understand the state of their environment to create significant change. Companies should analyze their security maturity and discover how to encourage developers to supplement and further strengthen it.

Developers want to understand the impact they have on a project and do quality work that makes a tangible difference. Often, though, they find themselves battling unrealistic timelines that result in an inferior product. Managers want the same thing, but they need to communicate better on how to reach these goals.

Organizations should communicate the importance of a security-centric culture and how developers can make an impact on a large scale. It is up to company leaders to find innovative ways to highlight this impact and, most importantly, create a structure where this work is rewarded and valued. 

Security as a Shared Responsibility

Security is not just for individuals with the word “security” in their title, but an organizational effort. Developer enablement creates opportunities to embed developers into larger corporate practices and goals, not just assigning them seemingly free-standing development tasks. Make them feel invested in the organization’s overall success by creating an environment where CISOs, security teams and developers work together to improve security posture.

Outline practical steps that can make incremental changes. Organizations too often try to take on too much at once (the boil the ocean approach), ultimately leading to failure. Instead, make security a teamwide responsibility that leverages the skills of each part. Developers want to feel valued in their work and should feel empowered to refine security protocols during the development process.

Encourage Ongoing Education

Education is integral to the improvement of developers’ security prowess. Organizations often do not provide developers with the upskilling opportunities needed to further enhance their skills with tight deadlines, project demands, and other more immediate needs taking precedence.

If developers receive training, it often takes place during a single day, and rarely features valuable long-term information that makes sense in the context of their day-to-day work. Organizations must move past this approach and look to create upskilling incentives to create well-rounded developers. They need to leverage scaffolded learning techniques that allow developers to follow individual programs that build on top of one another.

Organizations that emphasize continuous learning, knowledge and upskilling will create well-rounded developers who create better programs, stay loyal to their company, and help build a strong security posture. Successful leaders often set a cadence of developer training programs and emphasize continuous learning. These training opportunities should be prioritized and not moved aside for other priorities. 

A Look at What’s Next

The future of developer enablement is creating an environment where developers can thrive, providing opportunities for developers to collaborate across the security organization and ensuring they have access to the appropriate education and training opportunities.

As a company leader, this is a chance to make real change. Use this as an opportunity to reset how your organization works with its developers. Leverage tools that embrace new, innovative training methods that will empower them. Doing so provides immediate benefits to company culture and can help improve code quality while reducing developer turnover.

The post The future of developer enablement in software security appeared first on SD Times.

Software testing was mostly a manual process, and the people developing the software typically also tested it. Seeing a need in the market, consultancies started offering outsourced software testing. While it was still primarily manual, it was more thorough. Eventually, automated testing companies emerged, performing high-volume, accurate feature and load testing. Soon after, automated software monitoring tools emerged, to help ensure software quality in production. Eventually, automated testing and monitoring became the standard, and software quality soared, which of course helped accelerate software adoption.

AI model development is at a similar inflection point. AI and machine learning technologies are being adopted at a rapid pace, but quality varies. Often, the data scientists developing the models are also the ones manually testing them, and that can lead to blind spots. Testing is manual and slow. Monitoring is nascent and ad hoc. And AI model quality is suffering, becoming a gating factor for the successful adoption of AI. In fact, Gartner estimates that 85 percent of AI projects fail.

The stakes are getting higher. While AI was first primarily used for low-stakes decisions such as movie recommendations and delivery ETAs, more and more often, AI is now the basis for models that can have a big impact on people’s lives and on businesses. Consider credit scoring models that can impact a person’s ability to get a mortgage, and the Zillow home-buying model debacle that led to the closure of the company’s multi-billion dollar line of business buying and

flipping homes. Many organizations learned too late that COVID-19 broke their models – changing market conditions left models with outdated variables that no longer made sense (for instance, basing credit decisions for a travel-related credit card on volume of travel, at a time when all non-essential travel had halted).

Not to mention, regulators are watching. Enterprises must do a better job with AI model testing if they want to gain stakeholder buy-in and achieve a return on their AI investments. And history tells us that automated testing and monitoring is how we do it.

Emulating testing approaches in software development

First, let’s recognize that testing traditional software and testing AI models require significantly different processes. That is because AI bugs are different. AI bugs are complex statistical data anomalies (not functional bugs), and the AI blackbox makes it really hard to identify and debug them. As a result, AI development tools are immature and not prepared for dealing with high-stakes use cases.

AI model development differs from software development in three important ways:

– It involves iterative training/experimentation vs. being task- and completion-oriented;

– It’s predictive vs. functional; and

– Models are created via black-box automation vs. designed by humans.

Machine learning also presents unique technical challenges that aren’t present in traditional software – chiefly:

– Opaqueness/Black box nature

– Bias and fairness

– Overfitting and unsoundness

– Model reliability

– Drift

The training data that AI and ML model development depend on can also be problematic. In the software world, you could purchase generic software testing data, and it could work across different types of applications. In the AI world, training data sets need to be specifically formulated for the industry and model type in order to work. Even synthetic data, while safer and easier to work with for testing, has to be tailored for a purpose.

Taking proactive steps to ensure AI model quality

So what should companies leveraging AI models do now? Take proactive steps to work automated testing and monitoring into the AI model lifecycle. A solid AI model quality strategy will encompass four categories:

– Real-world model performance, including conceptual soundness, stability/monitoring and reliability, and segment and global performance.

– Societal factors, including fairness and transparency, and security and privacy

– Operational factors, such as explainability and collaboration, and documentation

– Data quality, including missing and bad data

For AI models to become ubiquitous in the business world – as software eventually did – the industry has to dedicate time and resources to quality assurance. We are nowhere near the five-9’s of quality that’s expected for software, but automated testing and monitoring is putting us on the path to get there.

The post AI needs automated testing, monitoring appeared first on SD Times.

Flip a coin a hundred times and half the time it will come up heads and half the time it will come up tails. Project estimates (effort, time, and cost)?—well that’s a different story. Antidotal information is that project managers are more than five times as likely to underestimate effort, time, or cost than overestimate them. Why do we underestimate so often? Well, perhaps it is in our genes. If we ignore for the moment evolutionary biology, genetics, neuroscience, neuroepigenetics, phylogeny, phrenology, not to mention the Hardy–Weinberg principle, we see how underestimation is an evolutionary advantage for our species. How many times have you said that if you knew how hard it was going to be to do something you never would have undertaken it? If Thomas Edison knew how hard it would be to invent the light bulb would he have tried? Had the U.S. Congress known what the Webb telescope would eventually cost, would they have funded it? Underestimating is a tremendous advantage for our species, for it allows the creation/discovery of things that rational minds avoid.

However, while some evolutionary traits are an advantage for the species, they can be a disaster for the individuals of that species. For example, salmon swimming upstream to spawn is good for the salmon species, but the individual fish does not survive the journey. And the praying mantis who eats her mate—well let’s not even go there. Similarly, while underestimating might be essential for the human species to advance, it can play havoc for the individual, such as a project manager. 

The reality of the situation is that whatever you do, you might be destined, perhaps by some aberrant gene, to underestimate the effort required to build your system. This is the estimation conundrum. The systems development Kobayashi Maru. The no-win scenario.

There is only one practical workaround for this genetic peculiarity—feedback. The project manager needs frequent, timely, and accurate feedback as to the quantity and quality of all functionality produced along with the time and cost it took to produce it (See “Planning for the Perfect,” SD Times, March 2020). With constant feedback the project manager can finally overcome his or her genetic destiny. The number one source for understanding the scope of actual project deliverables and their costs is the post-project review (PPR).

The project’s PPR is a chapter in the project manager’s and IT’s history book. It provides necessary feedback so that the project manager can continually learn and improve project management skills. It can also be a valuable learning tool for other project managers, or would-be project managers, as to what to do, what not to do, and what to avoid like the plague.

The Internet is awash with PPR templates and sample reports free for downloading. You need only pick one and follow it. They all look a bit different, but the differences are largely unimportant if they include a traditional mathematical look at schedules, staff effort, costs, deliverables, etc. as well as two additional critical components. The first is lessons learned, a review of the project’s successes and failures. This section is the lynchpin for any hope for future project managers to learn from the experiences of those who went before them. The project manager should detail what worked, what didn’t work, and why. All subjects are fair game including tools, techniques, staff (user and IT), productivity, user availability, vendors, testing issues, working conditions (office space, technical resources, pizza delivery, etc.), and even those moments of brilliance as well as the mistakes made by the project manager. 

The second critical component is recommendations for future systems development projects, where the project manager speaks to future project managers (or his or her future self), detailing what future project managers should look for and what they should do differently. Think of Dear Abby giving lovelorn advice, only here the advice is for the managers of future projects.

However, this is only possible if a robust and truthful PPR exists. Many PPR tasks are included in initial project plans but they are eaten up by the two PPR enemies: poor project planning and scope creep. Once the project manager discovers that schedules or costs will likely overrun the plan, then the hunt is on for the tasks that can be sacrificed. The PPR is often the first. The 20-person day PPR is cut to 10 days, then five days, and then completely eliminated in an IT sleight-of-hand.

There are a few critical success factors for a good PPR.

1. Bundle the PPR into the Project Plan. The best way a project manager can increase the chances of a decent PPR is to bundle the review (including its schedules and costs) into the project plan. Some user managers might balk at paying for a PPR. Telling one user organization that they are being billed for a task that might only benefit another user organization is often a non-starter. If the PPR is a seamless part of IT’s development methodology, then it might very well pass user scrutiny. If it becomes an issue with user management, then the project champion might be useful in convincing the user of the value and importance of a robust PPR (See “Projects, Politics, and Champions,” SD Times, March 2022).

If user management refuses to fund the PPR then the project manager should encourage IT to foot the bill. It might take some selling (See “Half of Managing is Selling,” SD Times, November 2020) but if the project manager focuses on the benefits to IT, all might turn out well. If IT doesn’t have the funds to pay for the PPR directly, then IT might consider the cost of the PPR a project overhead item and bundle it into IT’s daily billing rate.

2. Positives and Negatives. This is not summer camp where every kid gets a trophy. Lay out what went well but also point out what could have been done better. Do not defend what is not defensible. If IT management failed to have needed developers or development tools available on time, say it. If user management never provided the promised space the team needed, say it. If the project manager miscalculated testing time, ‘fess up. (Don’t worry about retaliation. When was the last time a user or IT management voluntarily read a project team deliverable?)
3. Be Honest and Objective. There is no sense in going through the effort of a PPR if it becomes a puff piece (just the good things) or thin soup (a two-page Hallmark card congratulating the team). Remember all those times you went home frustrated and kicked the dog? This is the opportunity to explain those vet bills, cleanse the soul of the disappointments with being a systems developer, and help the next project’s team members with better canine relationships. 

Honesty is particularly needed in understanding project productivity. Accounting can give you an accurate “dollars spent” (cost) on the project, and HR the staff hours consumed (effort), both of which might be the only numbers that senior management cares about. However, for understanding productivity, both of these numbers are meaningless without also considering the work completed (the fully developed and tested functionality of the system). If functions were eliminated or their usefulness reduced, if testing was abbreviated, or if documentation was shortchanged, and these changes are not taken into account when calculating productivity, then a false number will emerge, the cycle of poor and inaccurate feedback will continue, and any hope of project managers learning from their experiences will evaporate. Ensure that the actual functionality delivered is the basis of any PPR.

4. Include Many Inputs and Many Comments From Many People. The PPR is not the project manager’s opportunity to settle scores. Every team member, IT and user, IT management and user management, should have the opportunity to add his or her comments and rants to the PPR. However, the PPR is not a social media blog. There should be an “official” opinion penned by the project manager. However, just as the U.S. Supreme Court might have a minority opinion accompanying the opinion of the majority, there should be an opportunity and place in the PPR for those who disagree with the project manager’s conclusions to post their opinion. 

There are four important PPR takeaways: 

1. Unless you are retiring after the current project, past projects can help you perfect your skills for future projects.
2. The PPR is the best vehicle for learning from past projects.
3. Use the PPR to build a picture of yourself as a project manager. (a) Where do you habitually underestimate or overestimate? (b) What should you have done differently? (c) What processes, data, or personal skills would help you be a better project manager?
4. Tell the truth—lying, shading, or coloring what really happened is a waste of precious project time.

Done properly the post-project review can be one of the most useful and most cost-effective tools in IT’s systems development arsenal. It will also please your dog.

George Tillmann is a retired programmer/analyst, project manager, and CIO. This article is adapted from his book, Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com. 

The post The Project Management Task You (Almost) Never Complete appeared first on SD Times.

Prioritization over perfection 

Perfectionists can be tempted to spend countless hours trying to improve the codebase, distributing the coding best practices, asking for more hours to refactor, and fixing every bug in the backlog that they can get their hands on. However, fixing the bugs customers don’t complain about in a feature that is not heavily used is not a good use of time.

Prioritization should be at the heart of a Senior Engineer’s approach to work. Software engineers need to fight the urge to pursue roads that do not provide value to the business and block their impact.

Crystal clear clarity 

Senior Engineers are not just delivering code – they are delivering solutions. Avoid trying to fit design patterns where they are not needed and looking for ways to make the code “prettier” to fit a specific aesthetic. The reality is that no one cares about unique aesthetic preferences, but rather they care that the solution makes an impact and would survive year after year. 

Engineers should pick clarity over complexity when writing code, designing architecture, communicating a piece of information, or advocating for a new piece of technology. By doing so, the solution has a better chance of making an impact and surviving over the years.

A lot of software engineers want to play around with shiny new technology, or a new programming language. Take a step back and look for opportunities to accomplish the same goals within the existing tech stack. While new tech is cool, keep in mind that even the overhead of learning and teaching a new piece of technology in an organization can be burdensome.

The piece of code no one wants to touch is the one that has a complex design and is not necessarily the most difficult.

As Martin Fowler said: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” 

Make it a priority to deliver solutions for humans.

It’s not just coding, it’s also talking about code 

A common pitfall software engineers fall into is forgetting to focus on soft skills. An engineer that writes code the fastest and can produce complex solutions isn’t necessarily prepared for a senior title. 

A Senior Engineer is expected to articulate every solution that belongs to them, from the past or in the present. If an engineer is unable to explain their reasoning behind a solution they have built, it signals that they are just following what they see from others and not putting thought behind every decision they make.

At this level, precision is key and execution at both the technical and communication level is indispensable. The bottom line is that a Senior Engineer does not have to be the one that can write the most code, but they must be the one that can clearly explain every solution they build.

Focus on ‘Get it Done’ and ‘Figure It Out’ Principles

As a Senior Engineer, you need to accept that the training wheels are off and you are mostly on your own. Your peers and leaders expect you to take care of business day in and day out without receiving any hand holding. Long gone are the glory days of asking questions without shame or taking a week or two to come up with a solution.

The reality is that being a Senior Engineer is not easy, and the road is definitely bumpier ahead. That is why the realization that “just work”’ is not enough, and you may need to put in extra effort to keep adding to your skillset.

At this level, you have a responsibility to keep pushing yourself every day to learn and grow and to challenge yourself to get faster and deliver value promptly. 

What’s important to the business is now important to you 

Ultimately, this is the most important principle to chase as a Senior Engineer and critical for the next generation of talent.

Do not think that you are just there to do what you are told or sulk when working on a project you are not fond of. We are all in this profession to provide solutions where they are expected, and we must continue to do that. Sometimes it’s a software engineer’s job to poke their nose into things and find out what is preventing their business from delivering more value and make the case to go build it.

It might not be possible to solve all the big problems an organization or users might have, but you can start from somewhere. The best approach you can take is to act as a good scout and leave the place better than you found it. Take the lead and inspire others to follow your steps.

The post A Senior Engineer’s Survival Handbook appeared first on SD Times.

If the Great Resignation has taught us anything, it’s that developers who are tired of workplace culture don’t stick around. Average tenure at some of the most prominent tech companies in the world is under two years, and when they leave, they often take valuable code, customer contact lists, patent applications and much more with them. For senior developers and team leaders, it’s a high price to pay when employees start sniffing around for other opportunities. 

Fortunately, you can take steps to reduce turnover, many of which aren’t complicated or time consuming. In today’s super competitive environment, one of the best ways to make your company a great place to work—and to keep developers happy—is pretty straightforward. Just back off. Trust them to do their jobs well.

This is key to building a supportive environment where developers feel comfortable voicing their ideas—particularly if those ideas are unpopular. Leaders have a responsibility to establish the kind of environment where values are reinforced, and to hire people who thrive within this framework. Even if that means they’re not always hiring the candidates who seem like an obvious fit.

Even Dumb Ideas Can Be Valuable

I know this because I have lots of dumb ideas. I’m thankful that, over the years, my colleagues have actively encouraged me to share those ideas. It taught me that I can build and foster a company culture where new ideas and new ways of thinking are valued, even if those ideas aren’t immediately well received.

Something that might seem like a dumb idea at the time, can actually evolve into something remarkable. By encouraging people to share their ideas, you can foster a sense of trust and innovation that leads to an explosion in creativity. It also makes your organization stronger by reducing employee stress—stress which ultimately leads to burnout and turnover.

Employees know they’ve long been perceived as replaceable cogs in the corporate structure, and not as unique individuals with valuable skills, and yes, shortcomings. So, fostering a culture that’s truly human and invites vulnerability has to be done with intent and deliberation.

People want to feel authenticity in where and how they work—that’s why it’s valuable to talk about new ideas (even dumb ones) to ultimately improve the company and its products. Fostering a supportive culture will likely lead to disagreements, but there are ways to offer opposing viewpoints without being a jackass. This mutual respect between developers allows your entire team to look at things through a critical lens without stepping on other people’s toes.

Here’s one example: at CodeSee, we do regular product reviews, which oftentimes lead to conversations where our developers say: “I really wish our product would do this instead.” Or “wouldn’t this be a cool feature to add?” This isn’t criticism leveled at anyone in particular, and everyone understands this. It’s a collaborative effort, with the aim of improving how our product works.

Take Steps to Sniff Out the Jerks in Your Applicant Pool

Some companies subscribe to the idea that if you’re a genius, it’s OK to treat people like garbage. We don’t. We’d rather have a decent developer who fits our culture and embodies self-reflection and humility, than a great developer who doesn’t support others. The same things we prioritize in our day-to-day operations are also reflected in hiring. There are easy-to-implement strategies to identify these qualities in potential new hires.

Two of our standard questions are simple and straightforward. We ask candidates to define three strengths and weaknesses. Three is a big enough number so that it requires introspection, and it helps us gauge if developers have already identified strategies for personal growth. The second question we like to ask is: “what will your previous managers say about you when we talk to them?”

These questions are meant to help us gauge whether or not the candidate has a pulse on self-reflection. If candidates can consider what it’s like to be one of their past managers, it shows a high level of self-awareness and empathy. And these are the people who tend to make it through our hiring process. 

Conversely, we’ve seen these questions absolutely sink some applicants. Some of them suddenly feel uncomfortable—I’ve actually been yelled at on more than one occasion. Can you imagine yelling at the person conducting your job interview? Yet it happens, and at that point, it’s game over.

Finding the Right Tools for Success

Providing the right tools is another way companies can foster a positive culture. Consider the responsibilities managed by today’s developers—especially those on teams who’ve implemented DevOps best practices. It’s not surprising that many are seeking tools to help them reduce time in tasks like project onboarding, feature planning, and code review; they’d rather focus on actual development.

Today developers spend over half of their time reading code. But what if we could cut that by just 20 percent? Or even 40 percent? If your software developers could spend 40 percent of their time doing other things, it would be truly transformative for business.

Of course, productivity tools can have drawbacks. Instead of giving more freedom and trust to developers, some organizations use technology to try to squeeze every last scrap of productivity out of them. If that’s the case, the underlying message your employees may hear is, “You’re getting a new, expensive tool because you aren’t being productive enough.” There’s no better way to push talented developers towards the exit.

Ultimately everyone needs developers, and they’ll be well compensated wherever they land. So, while some turnover is inevitable, a lot of it can be avoided if you’re intentional about crafting and maintaining a supportive work environment. And the creative energy you foster will help ignite product innovation.

The post Don’t lose developers to bad culture appeared first on SD Times.