Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Motley is a programmer who has been in the industry for a while who has good technical skills but continuously practices a wide assortment of archaic development methods. Motley is a little egocentric and is perpetually and naively handing out bad advice. Motley is often a bit of a brute and full of sub-optimal tips, but because he is a senior engineer, people listen.
Maven is an altruistic software engineer that is extremely knowledgeable in the practice of software development and wants to educate the industry on how to engineer software in the most effective way possible (among other things). Maven is somewhat of an idealist, but his arguments generally hold water and can help guide any software engineer.
The interaction between the characters serves to motivate different aspects of software development and engineering practices and features of improved methods. The unfolding of key concepts and the tension around their application is developed in a progression. Waletzky introduces additional resources and some exercises as well. Here are key themes and topics that I commend to all budding cybersmiths. James welcomes feedback and comments. The comment discussions there are valuable additions to the basic articles. All interpretations on what the point is be mine:
2007-07-10: Motley says: "Refactoring means no more up-front design" on "just-enough" and critical design efforts that forestall a mess that can't be refactored out of. Avoiding refactoring as a design-loss rescue technique (it being exquisitely painful to re-engineer something that was not engineered in the first place)
2007-08-28: Motley says: "Code comments are for sissies" "Comments are extremely valuable in code when they convey useful information that the code itself cannot. For example, the code itself cannot express the intent that the developer had when she first wrote it. The code itself cannot tell you why the code is the way it is. Sure, a good developer can figure out how it works, but the why may not be obvious. Good comments express intent." There is far more juice in the article, including differentiation between design documentation and code comments, although comments can support design and requirements tracing. [Notice that I did not create a documentation category for this. This is here because it is as important as contracts and it is about the quality of the code itself.]
2008-04-08: Motley says: "Native C++ code development is obsolete" It is interesting that the war over choice of languages and tools falls here beneath guidance about multi-dimensional decision analysis. Here, Motley expresses his commitment to C# and never looking back on native code development. Maven (and Waletzky in the comments) expresses his preference for .NET too, with argument that there remain important places for native code, even on the desktop. I think the most telling observation is Motley's concession that his knowledge of C++ has made him more knowledgeable in his use and understanding of C#.
2008-06-11: Motley says: "Don't be anal about API design" [You probably would not be surprised how anal I am about API design -- dh:] Motley is concerned about a design review that proposes an API that concerns him, yet he doesn't want to be anal about. This post works through the principles and what to look for in exemplary APIs in existing libraries. Maven sums it up nicely: "Good APIs are discoverable, consistent, simple, usable, hard to misuse, cohesive, lack side-effects, strongly typed, documented, has tests and samples, extensible when necessary, and are developed with anal minds." There's a nice punch at the end, along with a couple of useful links.
2007-08-14: Motley says: "If-then-else hooks are the best way to inject mock objects" Maven: "... Once you have well defined interfaces between your component boundaries, you can plug and play different implementations - mock objects are a great example. But, that's not all. You need to employ a simple technique to invoke the mock objects when required. The first technique is known as "dependency injection."
2007-09-18: Motley says: "Just use a batch file to run unit tests" Maven describes test frameworks and their advantage over hand-rolled individual test executables [what I've been doing]. Maven's point: "It's not important what framework you choose - even if its homegrown - but it is important to use a well-written framework. ... If you decide to implement your own, sticking to the pattern mentioned ... will ease the learning curve for test writers."
2008-05-13: Motley says: "Too many assertions make debugging very annoying!" I confess that I have never used assertions. I don't use debug builds and the debugger either. I am one of those folks that only builds release versions and finds other ways to debug them. Because I would not ship something with assertions in it, I have simply avoided assertions. In this article, Maven expresses similar sensibilities (to my surprise) but views assertions as an element of defensive programming. I'm all for defensive programming and I am very strict about it in the libraries I build. I can see adding assertions while debugging as a way to verify that the problem does not involve an incorrect precondition assumption. Maven quotes a co-worker with a statement that I can completely align with: "If you are assuming anything without verifying it in either the code or an assert, you’re walking a tightrope without a safety net." So why am I so fussy about not using debug builds? Well, compilers do have bugs and there can be an optimization bug that only exists when the assertions are not compiled. But mostly, I want to be always working with the release build and live assertions are, for me, as dangerous as uncaught exceptions. I recommend this post. There's a list of conditions that assertions should be used for and it is an important exercise to determine how you could detect those failures without using run-time assertions and still defending your code. And I don't expect that many others share my obsessiveness about testing and debugging with only release builds.
2007-09-25: Motley says: "Individual gut-feel estimation is the only way to estimate" dispels the notion that, because "Developers are never accurate on any project longer than 3 days!" and because estimates are never perfect, "the only real way to estimate is to go off gut feel." Maven asks about past experience and then suggests estimation methods that depend on using a group of estimators. Even as a terrible estimator, I have some qualms with this, especially since I rarely have access to estimations of others. The references provide additional guidance, and there is more active discussion on the web about narrowing the window of estimation (and shrinking the cone of uncertainty at the same time).
2007-10-09: Motley says: "The only tool that I need is the debugger (Part 1)" This topic is about the relationship of a developer and tools. The illustration of tools that handle certain explorations far more efficiently than stepping through debugger breakpoints is useful, although definitely down in the weeds. The importance of finding measurable behaviors and accounting for interactions is not to be under-estimated. Some additional context-setting might be called for [especially for me, since I rarely use the debugger for anything].
2007-10-16: Motley says: "The only tool that I need is the debugger (Part 2)" Inspired by the previous discussion, Motley discovers some other tools and plug-ins that support .NET development as well as general development on the Windows platform (.NET Reflector, Notepad++, etc.). The duo begins to swap what they know about different ones and embark on a search for additional tools. There are some useful thumbnails and links to further details.
2007-10-23: Motley says: "Quick peer reviews are sufficient. Team reviews? Waste of time" This is a great illustration of the value of inspections and also the level of inspection and review that may be appropriate to the situation. The situational aspect (and developing good judgment of appropriate action) is crucial in approaching all development models and methodologies for adoption. Useful references.
2007-10-30: Motley says: "Inspections suck ... time that is" Maven elaborates on inspection as applicable to all of the artifacts that go into a software development, not limiting them to code reviews and walkthroughs. The process is structured (and can seem too formal) although the motivation is clear, especially with the importance of preparation. There are important social considerations that arise in inspection processes and I don't know how much the referenced materials address that. There's something about diligence and trustworthiness and checking on ourselves as affirmative processes to keep in mind.
2007-11-06: Motley says: "I just get picked on when my code is reviewed" An extremely important feature of inspections is defusing criticism of the developer and providing constructive contributions. It is also extremely important to avoiding matters that are not to be inspected for and that can devolve into geek-religion disputes. Finally, as pointed out in this post, it is important to avoid instant design and creation of solutions to identified problems. This is both dangerous and completely distracting. The key goal is identification of problems and agreement on what they are. Another message here is that programmers should be eager for inspections because of the early uncovering of problems. It takes a while to build the trust structure that encourages this.
2007-11-13: Motley says: "Ugh, not again..." When Motley proposes public executions for developers making the same mistakes over and over again, Maven provides a delightful romp through root-cause analysis and taking actions that address the cause rather than dispense punishment. Interesting links to further materials.
2007-11-20: Motley says: "Performance stinks, but I'll deal with it later" Motley is using a profiler to find the slowest parts of a program without concern for which parts are the most important. Maven's advice is to think about performance early in the development cycle, not with add-on end-of-development profiling. Most important is having performance metrics from the beginning, and having measurement in place from the outset as well. Two issues come up: the opportunity cost of optimization where it doesn't matter and the bigger gains that can be achieved by designing for the performance-critical requirements of the program's application. I'm thinking this will provide some tension with problems of premature optimization, so there needs to be consideration for the level at which performance is addressed from design through to preparation for deployment. There are not fixed guidelines but there are hints to product- and platform-specific resources.
2007-11-27: Motley says: "Consulting? I guess your answer from here on out is 'It Depends' " (HPT Part 1) Introducing Human Performance Technology and its application in development process and team performance for getting to the root cause of problems (too many broken builds, code churning, and other detractors from development success). The technology (i.e., know-how) is one illustration of problem-solving and optimization that can be used to understand the opportunities.
2007-12-04: Motley says: "Human Performance Technology? Do I need a profiler for that?" (HPT Part 2) Continuing on the previous discussion, the environmental (as opposed to individual) dimensions that impinge on a problem and related opportunities are explored. This is a cross-cutting topic that applies to personal and professional development and also development of management skills. It matters for having successful development processes, and it extends more broadly into workplace performance matters.
2007-12-18: Motley says: "Human Performance Technology? I guess I better brush up on my robotics." (HPT Part 3) Continuing on the previous discussion, the individual (as opposed to environmental) dimensions that must be considered in finding root causes and solutions to problems are discussed. It is pointed out that training is not always the appropriate action to addressing an immediate situation and, it seems to me, the ready-to-hand capabilities are of greater importance along with the broader view towards developing the team and the capacities of the team. The wrap-up circles back to the emphasis on performance and introducing measures to verify that the solution was effective as well as find any new lessons.
There is also some personal productivity in some of the later posts. I am too lazy to restructure yet, but I'm a-pondering. -- dh
I see that we are moving to software engineering and project management topics here and it is time to start a different category for the Human Performance Technology and agile management topics. Later ...
2008-01-22: Motley says: "What does Rugby have to do with software?" (Scrum Part I) Beginning a discussion on agile management practices and especially scrum meetings (with some very on-topic comments). The narrative builds naturally to the basic scrum process, with emphasis on having small increments with completed work. The comments raise some important concerns on what "done" means and how it is important not to be squirrely about it.
2008-02-19: Motley says: "What are we burning down? Your house?" (Scrum Part V) opening up a major difficulty in all software development, estimation of time remaining and also tracking time spent well enough to be able to understand what is happening with project velocity. The social issues are addressed and the value of tracking effort in a non-judgmental is worked through with interesting graphical examples.
2008-02-26: Motley says: "If computers can efficiently multi-task, so can I!" looks at the cost of attention changing between tasks that require concentration and focus both in terms of personal productivity. The point is then applied to examination of Scrum Burndown charts and making sure that there aren't so many in-progress tasks that the team is driven to inefficient performance.
2008-03-04: Motley says: "Checklist? We don't need no stinking checklist!" My life is maintained in checklists, and I make checklists every day. With regard to recurring checklists I could use better tools (and reminders to use them). Here the importance of checklists is reviewed and some great ideas for removing the friction from team and personal checklists, as needed in code reviews and other situations where memory is not enough, is illustrated and then supported with some great links. There is a revolution occurring around checklists in medical procedures that demonstrates the importance of these things (as does the value of checklists in aviation and other safety-critical activities). For me, my memory is a steel sieve and I would be lost without checklists. A great read.
2008-03-11: Motley says: "Affinity exercises? How do I work that sideways '8' into brainstorming?" There were some difficulties agreeing on a checklist and Maven explains affinity exercises for brainstorming following by prioritization according to an allocation-voting procedure. The example is agreeing on the key items for a code-review checklist, but this can be for anything including planning an event to prioritizing features.
2008-05-20: Motley says: "Spend less time in OneNote and more time in Visual Studio" This is a bare-faced paean to Microsoft Office OneNote used as a collaborative shared-note-minding tool. Maven describes OneNote characteristics for collaborative creation and maintenance of all of those artifacts other than code that must be developed and maintained in the course of a software development. The step-function for using OneNote (and the cost of yet-another proprietary document format) in this way involves a pretty serious commitment to the Microsoft Office System among the members of a development team. When this pill is too large (or the project is distributed in a way where it is simply impractical or unaffordable), other, lighter-weight approaches must serve. Project wikis come immediately to mind, as well as use of distributed versioning for documents. Some people even use their bugtracking system this way, although that can be confusing if carelessly used. What tools work for your (distributed) project-team collaborative-document and speedy note-taking and informal status needs?
2008-05-27: Motley Says: "Bug fix sprints are a Scrum anti-pattern" This juicy post focuses on the tension between getting it done right, with agility, and the likely case that there will need to be a stabilization activity at some point. The importance of having or restoring a common understanding of "done" and having a quality or integration sprint toward Zero Bug Bounce are both treated. Maven makes a strong point about keeping records of fix effort so that there is some understanding of what a bug-fix will take.
2008-06-24: Motley says: "Milestones are useless for agile development" This is an intriguing exploration of how milestones are different than iteration completions and may have strong exit criteria. The tension between process requirements above and beyond the iterations of individual contributing teams is described in useful terms. Critical software-engineering tip from Maven: "Avoid cheating on the exit criteria when the end of a milestone draws near and the project manager does not want to change the date. You are only cheating yourself. Do your best to meet the exit criteria and maintain high product quality even in early milestones. Revisit the exit criteria for future milestones if the exit definition is too strict."
2007-12-11: Motley says: "I fear public speaking more than I fear dying!" digs into technical proficiency, expanded influence, and communication skills as important for becoming a senior developer, crafted around Waletzky's return from speaking at the Agile Development Practices 2007 Conference. That talk, on balancing Big Design Up Front (BDUF) and emergent design (the kind that agile iterations result in) is useful to me in some nano-ISV projects I have. The slides are available.
2007-12-13 Human Performance Technology and other processes for identifying team performance improvement opportunities are also relevant to this topic (see entries for 2007-11-27 and later under Development Methodology).
2008-04-15 Motley says: "Back to that public speaking thing - yuck" The summary and the conversation provide important tips. Maven: "Public speaking requires a lot of practice and know-how. Have a good objective, know your target audience, set expectations, use minimal slides as a visual aid, practice, use a summary, and work on your bad habits. Above all, be passionate about your topic!"
2007-08-21: Motley says: "The best way to get what you want is to complain ... loudly!" This is about how to be served by being someone who invites service, something that matters in many producer-adopter relationships. It is how you can empower yourself as a customer and it gives an eye to how much there is a cooperative partnership involved, however momentary. Looking at what your best experiences of service and care by suppliers have been is an useful invitation to look at how you support the adopters of your own work.
2007-10-02: Motley says: "Seeing my manager in the hallway is all the interaction I need" Motley claims regular manager meetings are pointless and casual contact works best. Maven points out the advantage of closely calibrating ones progress, leveling expectations, and tracking areas of improvement and development with a regular structure. The discussion ends up focused on feedback to the manager. That may overshadow the importance of building an empowering relationship in which feedback can flow in both directions. For more resources on that, learn about the conduct of walkthroughs (a peer process) and scrum (a team process). Place careful attention on Maven's encouragement of Motley to be the driver in setting up and managing regular one-on-ones. [Added 2007-10-24: It all comes down to trust and being trustworthy. In particular, you have to be willing to trust your manager or you will undermine your own trustworthiness.]
2007-12-13 Human Performance Technology and other processes for identifying team performance improvement opportunities are also relevant to this topic (see entries for 2007-11-27 and later under Development Methodology). I am not thrilled about the naming and emphasis. Look into the treatment and links for understanding of how this applies to having successful teams.
2008-01-15 Motley says: "Meetings: None of us is as dumb as all of us" There are two things here: how to be at a meeting (and even deciding to go) and how to create and conduct a meeting. These are both important for having successful meetings. Especially important is how, as a prospective attendee, one can empower the success of meetings. Look for that in this post.
2008-04-22 Motley says: "The management team refuses to change. I give up." Motley is feeling demoralized by the failure of management to seize on the agile-style development approach his team wants to adopt. The coaching is, in effect, to see the situation from the perspective of management and their needs in having a successful organization. It is useful to look at all of the ways that the given scenario is about empowerment, and for whom.
2008-04-29 Motley says: "Management suffers from the "Crystal Ball Syndrome" when it comes to project planning" I'm sticking with the empowerment theme for this, although it addresses a serious project management theme as well: employing agile methodology underneath a waterfall-oriented system. The collision is around scoping, planning, and estimation for deliverables that have long-lead-time dependencies for down-stream organizations (whether internal or external). Any effort that is larger than what a single agile development team can embrace must content with the larger orchestration and risk-management concerns. Use this article as a thought-starter.
The Cybersmith gleanings are tips and guidance for developers who are past the novice stage. This level of discussion may not be that interesting while being a novice struggling to gain fluency with programming and the accompanying toolcraft. As one begins to comprehend the influence of larger considerations, these materials will assist in development as a cybersmith.
This is another page that I may simply update in place as James publishes more Motley and Maven dialogs. There are other sources (e.g., the writings of Ed Nisley and Steve McConnell) that contribute to deeper understanding of development processes and the techniques that contribute to successful outcomes. I intend to identify those separately.
[update 2008-07-04: Starting with 2008-05-27, Waletsky's posts are going to be bi-weekly, at least for the Seattle summer months. Oddly, the 05-27 and more recent posts didn't show up in my feed reader until today. I have no idea what that is about. update 2008-05-05: I notice that I am letting these slip. I need to refresh the organization and meanwhile I will simply be keeping up with James. update 2007-12-13: I feel awkward about the drift into discussion of Human Performance Technology but rather than fret about where it belongs in the coverage, I have mentioned it under two other topics as well as development methodology. update 2007-10-24: In adding the latest Waletzky post, I also cleaned up some text and expanded my observations on the empowerment aspects of the manager relationship. update 2007-10-16: I have brought this little catalog to be current and am wondering if I should stitch in some see alsos on some of these topics or employ separate posts. update 2007-09-05: Added a table of contents and some section-number permalinks to assist in future use of these clippings. update 2007-07-03, 2007-07-18, 2007-08-04, 2007-08-22, 2007-08-29: Continuing to add links for new posts. update 2007-06-28: I have started adding new titles as they appear, starting with the 2007-06-26 one on interviewing.]