Your current filters are…
by Ted Neward
It used to be easy: building an 'enterprise' app meant using EJB, or COM+, or Web Services. It meant building a big, high-throughput, transactionally-oriented client/server system in a server-side-heavy topology. But (they tell us) that's over now. It's all "cloud", and "mobile": small clients accessing large servers living in a data center "someplace else", in a high-throughput manner. Somehow it doesn't feel any different. Neither did mainframes, for that matter. How are we end up here? What's the new "enterprise" developer supposed to do? What about all the new stuff (dynamic and/or functional languages, "NoSQL", and more)? Where does that all fit in? And what does all this have to do with geometry and history, again?
If you are developing software and getting paid for it, software process is part of your life. Even the absence of a defined process is a process of sorts. For over forty years the world of software development has been churning through forms of process, with each successor disclaiming the validity of its forebears to the cheers of those liberated from the oppressive chains of process past.
But if the latest acclaimed process is the answer, why do so many groups slough off what seemed to be working well a scant few years ago in favor of yet another choice? Furthermore, the time between process changes gets shorter and shorter. Waterfall reigned for ages, then RUP, then Scrum and XP, and now Lean/Kanban, each enjoying successively shorter seasons of favor as the de facto choice. Process is but a framework to facilitate the collaboration of a group of people to produce a desired outcome. It is not a substitute for culture, technical excellence, discipline, and product strategy.
In this keynote, Barry emphasizes the need to continue thinking critically about the processes and practices we embrace, accounting for the context in which they exist, and the importance of reflection and refinement at both the organizational and personal levels
11th–13th January 2012