NDC 2013, Day 2
If the theme for my first day at NDC was high performance teams, the second day was all about architecture.
Asynchronous Programming on the .NET Platform
How does the user know your app is busy working and not broken?
I was reminded that about 250 ms are the longest an application should go without giving feedback to the user. This also applies to the application's startup time, which can be tricky in some situations. If startup performance cannot be increased within your development budget, a splash screen is your friend.
Seeing the differences between the asynchronous techniques in one coding session, made C# 5's improvements to clarity obvious. Thinking at a higher level of abstraction can be very powerful, but it also raises the bar for new users. However, every programmer today must learn to utilize more than one processing unit. C# 5's implementation of async and await is the most elegant I've seen so far in an imperative language.
People, Process, Tools – The Essence of DevOps
Richard Campbell gave me an introduction to DevOps. The discussion touched on some well known issues within a software organization, but it was still a useful introduction to the term DevOps.
This is the definition from Wikipedia:
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals
People, Processes and Tools, in that order, is the well known agile mantra and very much common sense. Richard talked about the challenges of cross-department and cross-team communication, and stressed the necessity of framing discussions constructively.
The one tip that stand out for me, was to focus on ROI (Return Of Investment) when discussing issues with stakeholders. For instance, if you cannot get managerial approval for faster hardware, document how much money the new hardware will save for the organization. Make it easy for others to make the right decision! Sun Tzu figured this out some time ago.
Other takeaways were:
- Document every project. Do not let problems or work go unnoticed.
- One step environment creation! Utilize virtual environments, preferably configured like production.
- Shorten and amplify all feedback loops.
- Take ownership of numbers that matter to you.
The Architecture of Uncertainty
Kevlin Henney is one of my favorite speakers, and I've been to many of his talks in the past. He has impressed me before by being one of the few speakers using sources from the scientific literature and not just anecdotes from his own experiences. If our field is to mature and improve, more educators outside academia must do this.
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
Therefore, we should
Avoid decisions at the point of most ignorance.
This have profound consequences. Don't lock in your decisions to early! We can use the stuff we are unsure about to help us define our architecture. Every point of uncertainty is a chance to introduce an abstraction such as an interface, enabling us to continue working without having to consider every detail all the time.
Partition the application along the lines of which you are uncertain.
Such thinking can improve the quality and speed of our work. It makes the gaps in our knowledge apparent and enables us to move forward in a constructive manner. As we come to know our project and domain better, the quality of our decisions will improve and it will be easer to fill in the gaps from before.