The programmer's new clothes

I often lament the transition from desktop to web application development. The web development ecosystem was so inferior to the desktop that we are still trying to catch up with the state of the art 20 years ago. One of the earliest victims of the move to web was performance. In desktop apps the expectation was immediate (maximum of a hundred milliseconds) response times. When the world wide web arrived we were suddenly facing 10-20 second response times. Dark days for user experience. Since the late 90s the web has slowly improved. We are now able to experience near-desktop performance with our web apps. Most of this is due to dramatically improved bandwidth. Another contribution was the move to ajax, web services and single page apps. Rather than making page requests for each transition we are now making very small, efficient data requests.  In spite of these improvements I still find teams setting very low expectations for performance (example: "3 second" service ...

In my formative years as a coder and architect I was mentored by several very talented engineers. One of them helped me understand a general goal of all engineering: simplicity. The best engineering is elegant in it's simplicity. Vehicles are my favorite example. The wheel itself? Incredibly simple, cheap and by far the most important component of a rolling vehicle. The internal combustion engine? A massively complex, polluting machine which we still struggle with more than 100 years after it's invention. I am so excited to see the electric motor become the heart of the automobile! In software engineering our goal is to create highly functional systems without creating great complexity. This is hard enough in itself but sometimes we needlessly create complexity by misuse (or lack of use) of borrowed code (e.g., libraries).  Good engineers are always on the lookout for borrowed code which solves a problem. The boon in open source in the last couple decades has made this a rou...

I can hear the snoring already.  Documentation?  The topic is documentation? As I mentioned in the welcome the goal of this blog is to shine a light on some things that we pretend are something they are not.  Nothing is more of this nature than the documentation of a software product. Nobody would disagree that documentation can be useful. It helps communicate intent to the person who we cannot directly educate. However, there several problems with documentation: There is a cost of creating it. If wrong it has more negative value than positive. It often calcifies our thinking.  Spending hours on something creates an investment in the idea.  So...our objectives are to make sure that: There is really a need.  The cost of creating the documentation should be merited because future team members (or perhaps even current team members) will be more efficient with this knowledge (or avoid screwing up something they didn't understand) The documentation ...

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...

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...

There are some advantages to getting older.  Less angst, less pretension, and a little bit more historical perspective.  The latter has been particularly useful for me during the last decade.  I have been developing software for almost 40 years (freaks me out to say that).  I still love writing code.  I feel very fortunate to have been born in the computer revolution so I could watch this fabulous change. I've titled this blog "The Programmer's New Clothes" as a suggestion that, much as the author of " The Emperor's New Clothes " suggests we often follow the crowd in a very silly manner. Ideas that do not deserve the import we dote on them can live WAY beyond the period whence we have discovered their significant weaknesses.   I don't intend this blog to be a " bile blog " (which I adored BTW).  In fact I don't think most of the entries on this blog will be critical at all.  Rather, the goal is to shine the light on subjects that ar...