I have a buddy from high school named Murph. His real name is Ben Felt but every legit teenage crew in Pitsford, New York in the 90s needed a Murph so Ben took one for the team.
He’s a quant. Like Taylor Mason from the show Billions.
In part one of this blog, I provided a high-level introduction to SAP Systems, Clients, Landscapes, and Transports and how they might fit together in a ‘standard’ configuration. But like life, SAP tends to be a bit more complicated than that. The reality of marrying architectural constraints with complex business needs means that the kind of simple landscapes I described in my last piece often will not do the job. Something more complex is required.
In this article – part two of three – I will look at some of the more advanced concepts associated with SAP Landscape Design and how to manage the increased complexity that comes with them.
Between November 2008 and December 2014, I transitioned from senior software engineer to dev team lead to Director of Engineering to VP of Engineering at CloudLock. During that time we grew from one office with 5 devs to four offices with 75 devs.
Let’s just say it was a crazy 6 years :-)
What’s your cycle time? If you can’t answer it, don’t worry, you’re not alone. Many engineering leaders couldn’t tell you without some significant number-crunching. Gaining visibility into performance is only half the battle though. Knowing how to interpret metrics and how to apply them to improving performance is where the magic happens. Many CEOs do not know how to align engineering metrics to business KPIs (revenue, customer retention, etc.). Bringing metrics to your board or non-technical CEO for the first time may be challenging if you are unable to help them bridge the gap.
Learn which metrics matter for engineering leaders.
It’s not controversial to say that low-code has become a trend in the development of turnkey solutions for business. However, low-code is not traditionally the first choice for developing systems that handle complex business tasks. One of the main drawbacks associated with low-code development is the limited functionality of applications created. Often platforms do not provide an easy way to add custom code.
In this article, we will discuss if a low-code platform could be flexible enough to describe the logic of really sophisticated business processes.
Two weeks ago I posted a blog on DZone about reinventing our daily stand-up meeting:
Stand-up 2.0: It’s time to ditch the daily from 1993
We don’t need a meeting to discuss individual status updates that could be a Slack message.
I was 24 years old. A baby.
Three years into my software engineering career and loving it.
No wonder. It was invented almost 30 years ago and we’re still running it the exact same way.
When daily stand-up meetings started in the early 90s, the software development process looked very different. Git didn’t exist. Jira didn’t exist. Collaboration tools didn’t really exist. DevOps didn’t exist. Automation tools didn’t exist. Analytics tools didn’t exist.
Software Testing and Defect Life Cycle are like two brothers from the same mother. They always go hand in hand when a project is being developed in the organizational paradigm.
In this article, we will tell you all about the different stages of the Defect Life Cycle that the software testers go through to provide a seamless and bug-proof product to their customers. Also, there are some frequently asked questions provided in the article to let you know about the queries testers answer daily.
