New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server - all still alive and kicking in some domains. You may be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others.
A relatively new kid on the block is DevSecOps. What does that mean? Where did it come from? Why is it important? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome?
In this session I’ll explore the origins of DevSecOps before going on to demonstrate the distance between the label and the intent of DevSecOps. Finally I’ll try to generalise the journey from “good idea” to “empty slogan” that seems to underpin many of the hyped transformations that I’ve lived through during my 40 year career in software.
Along the way I’ll describe a form of structured interaction that can relieve the tension between team autonomy and centralised control.
Consultant, coach, trainer, analyst, and developer for over 40 years.
Seb has been a consultant, coach, designer, analyst and developer for over 40 years. He has been involved in the full development lifecycle with experience that ranges from architecture to support, from BASIC to Ruby.
During his career, he has worked for companies large (e.g. IBM, Amazon) and small, and has extensive experience of failed projects. He's now Developer Advocate with SmartBear Advantage, helping to promote better ways of working to the software development community.
Regular speaker at conferences and occasional contributor to software journals. Co-author of the BDD Books series "Discovery” and "Formulation" (Leanpub), lead author of “The Cucumber for Java Book” (Pragmatic Programmers), and contributing author to “97 Things Every Programmer Should Know” (O’Reilly).