Skip to main content

Posts

Showing posts from February, 2017

Managing Risk and the Shadow Backlog

As an approach to developing software agile has had a profound impact.  There are many great architectures, languages, libraries, frameworks, etc. that have helped software engineering get better. But in my experience almost none of these has been as important as the process of agile. There are many advantages to agile but one of the most important but least articulated (especially to executive leadership...who should care the most) is risk management.  Unfortunately, this aspect of agile can also be misunderstood by the practitioners: the development and test team. So why does agile reduce risk?  Because the agile process creates transparency.  Nothing creates more risk than hiding information.  Nobody can make a decision to reduce/avoid risk if they are not operating with good information.  This is not to suggest that teams who are developing using waterfall approaches are intentionally hiding the truth of their project's progress.  Rather, the p...

We need a new front-end language

I like to preach to software engineers that       the essence of software engineering is    designing for complexity . I also preach that       coding = design . So transitively speaking       coding = designing for complexity . I deeply believe this (and you are going to hear it often in this blog).  While there are many important skills a coder brings to the job designing for complexity (DC henceforth) is our bread and butter. Yes, there are other important talents we bring to coding... Performant algorithms, Cool animations Understanding new and adjacent new technologies etc. These are important and often are the most fun part of the programming job but we spend most of our time (80%+) on DC.  A good programmer is thinking about design when writing every line of code.  "How will it relate to the other code in this app?", "how will it stand-up to change?", "will the next developer (or even me 6 month...