Wednesday, August 26, 2009
I am at the Software Craftsmanship North America conference in Chicago, USA.
I will be doing live coverage of the conference in this blog post, so do not be jarred if the content gets updated often.
Here is a twitter stream about it too:
Ken Auer kicked off the conference with a spectacular story about his upbringing both in and out of the software industry. He then proceeded to transition it to software craftsmanship and how he concluded that it is his favorite model for excelling in improving software development skills.
The first talk I attended was "There and Back Again" by Dave Astels, who recently left Google to join EngineYard, a very promising Rails hosting enterprise. His talk kicked off with a Software Craftsmanship version of the Star Wars rolling movie intro. The main emphasis of the talk is for developers to stick with technical work no matter how many ranks they ascend. Those who turn into complete managers cross to the dark side. In fact, that was partially why Dave left Google himself. He did not want to lose touch with the industry so he seeked more technical software work.
Next, I attended "Demonstrating Responsibility: The Mindset of Craftsmanship" by Christopher Avery. This was a talk on how taking responsibility is a key factor in succeeding with software development projects. Whether the process is agile or whatever new buzzword is out there. If team members are not taking responsibility, the chance of excelling and delivering is much lower.
Christopher mentioned the different emotional states people pass through when confronted with problems (sometimes skipping some) as a coping mechanism:
Denial > Lay Blame > Justify > Shame > Obligation
These states get in the way of being responsible, which gets in the way of solving problems and learning. In order to get through the states quickly towards responsibility, Christopher recommended adopting these attitudes:
Intention - The Winning Key: intending to recognize current emotional state and get beyond it
Awareness - The Change Key: being aware of current emotional state
Confront - The Truth Key: confronting current emotional state
Afterwards, I went to Jim Weirich's talk "Grand Unified Theory of Software Design". After quizzing the audience on common software design best practices such as DRY, SOLID, Law of Demeter, etc..., he proceeds to compare these practices to the early upbringing of physics and how there were many different theories in it before they were recently unified (partially) under M-Theory and Super-String Theory. He was wondering if he could do the same with software design principles, and his conclusion was that all principles seem to step from wanting to minimize connascence.
Connascence is a variation on the idea of software coupling, which is defined as follows:
"Two pieces of software share connascence when a change in one requires a corresponding change in the other."
Here are the different types of connascence he went through (C stands for Connascence):
CoName, CoPosition, CoMeaning, ContraC, CoAlgorithm, CoTiming, CoExecution, CoIdentity, CoValue, CoType.
Ward Cunningham talked next about how he designed computers with a completely different paradigm following the way bacteria communicates. In fact, the title of the talk was "What If Bacteria Designed Computers"
Next, I helped moderate a talk/panel given by Kevin Tayler, Micah Martin, and Carl Erickson titled "The Business of Craftsmanship." The audience asked quite a few interesting questions, such as, "How do you sell clients on apprentices working on their projects?", "How often does apprenticeship not work out?", "What happens if apprentices leave after investing in them?"
The last talk I saw before the final keynote was "Selling Craftsmanship in the Enterprise" by Cory Foy. One of the key points he made in it was: "The core of this movement [craftsmanship] is developers taking responsibility for their own careers."
Last but not least, I attended Bob Martin's incredibly dynamic keynote: "Craftsmanship Under Pressure".
Here are some traits he listed on what it means to be a professional:
- Can stay cool under pressure
- Under-commit but over-deliver
- Can have difficult conversations with the customer, like delaying the deadline.
- Know their field
- Live to learn. Love to Learn.
Great conference overall. It has been filmed, and you can find the sessions once announced on the @scna twitter feed.
That's all folks. Maybe we'll meet next year at this conference.
Thursday, August 13, 2009
However, once developers are comfortable enough with building web applications, they often seek ways to increase productivity and quality of work (performance, reliability, security, ...) through changes in software development processes and/or technologies.
As far as software technologies though, I've observed that developers too often only think of improvements that are incremental and within the box of what they normally do as opposed to outside the box.
What are some examples of in-the-box thinking?
- You have to program in two languages, one on the server and one on the client, in order to build a web application successfully.
- Despite your best efforts in adhering to web standards, you ought to spend time dealing with many browser-dependent issues while in the midst of building business web applications.
- You have to think about the low-level HTTP protocol details every time you build new business features in order to map them into service requests according to the web resource-oriented architecture.
- You have to code URL history management for Ajax calls yourself (with the aid of some library like YUI Browser History Manager or Really Simple History) to ensure that the back button and bookmark-ability are not broken in your shiny Web 2.0 application.
Having listed a few examples of in-the-box thinking, one may wonder "What is the box exactly made of?"
The box is made of all the currently assumed constraints that seem unchangeable, such as available development technologies, team values, and quality standards set by the client.
How do you think outside the box?
Thinking outside the box is an exercise in which people temporarily drop some (or all) of the assumed constraints and imagine how things would go about instead in that alternate reality. It is an exercise in creativity and imagination, and while it may yield some ideas that are not feasible in reality, it often yields other ideas that make people realize some of the assumed constraints are indeed changeable.
This is in fact what some luminaries in the Java world, such as Rod Johnson, did when they envisioned successful enterprise development without the constraints of EJBs (Enterprise JavaBeans). That's what DHH (David Heinemeier Hansson) did when he envisioned simplified web development relying on conventions instead of endless configuration files. That's what Google did when they built GWT (Google Web Toolkit), a framework that abstracts all the web low level details from developers.
In any case, often developers reject out-of-the-box solutions because they are not mature enough yet. For example, I know quite a few developers that are not very fond of GWT despite the fact that it offers these benefits:
- Unified debugging interaction for client and server making it very easy to trace data moving between them without having to context switch between many different syntaxes and technologies
- Abstracted all browser-related variations saving the developers from a huge burden in web development. Isn't that the premise of abstraction in software after all?
The reasons GWT is not considered a mature solution by some developers though are:
- Does not render web-standards compliant XHTML/CSS as it relies on the frowned up abuse of HTML tables to do layout
- Relies on the imperative Swing-like Java syntax to layout widgets, which is considered archaic nowadays compared to using DSLs that map closely to the visual layout, like Groovy SwingBuilder and SWIXML (or even good old XHTML)
- Of course, there is the learning curve and the fact that developers would have to remember to debug through an IDE instead of a browser debugger like Firebug. So, traditional web developers are kinda out of luck until they learn the new ways, but veteran desktop developers would be fine.
Still, the reason I bring this example up is because often when people get frustrated with a technology like GWT, they go back to accepting the status quo and working with solutions that are in-the-box as opposed to fixing the problems with the new out-of-the-box solutions.
The few that do persist and go beyond the box though end up with solutions that completely shatter existing expectations. For example, the Java language in its early days was considered by many developers as outlandish and impractical in comparison to writing code with a language that hits memory directly and works close to the hardware, like C/C++.
Who's making all the money now? :)