constructive nonconformist

Software Design Instincts

When I'm working out a software design I depend a great deal on my instincts, my unconscious competence. My instincts are in part an internalization of my experience.

I don't wait for experience to happen; I proactively build my experience through practice and experimentation.

Always be learning.

Jeff Atwood and Touch Computing and the Hunt-and-peck Pianist

In The Keyboard Cult on his Coding Horror blog, Jeff Atwood surveys mechanical keyboards. But he introduces his survey thusly:

As a guy who spends most of his day typing words on a screen, it’s hard for me to take touch computing seriously.

He trots out Scott Adams trotting out the notion that iOS is for consumption and not creation.

And deeper into his post he writes:

Maybe I’m biased. As I recently remarked on programmers.stackexchange.com, I can’t take slow typists seriously as programmers. When was the last time you saw a hunt-and-peck pianist?

Wow.

Touch typing on a full size keyboard, thumb typing on a physical smart phone keyboard, and 'typing' on a touch keyboard are different skills. The first two skills are related. The last skill is entirely different. The fastest raw typing speed on a touch keyboard will probably never approach the fastest typing on a physical keyboard. The real question is not which is faster, but if typing on a touch keyboard can be fast enough.

Atwood has highly developed touch typing skills and he's understandably frustrated that those skills don't transfer but how much effort did he put into developing 'typing on touch' skills before dismissing touch computing?

Activities that would be characterized as passive consumption requires less complex interactivity than creation activities regardless of the platform. But the disparity between consumption and creation activities is more apparent on iOS. There is a learning curve. It's not a steep curve but it's there. And it's a disservice to pretend otherwise.

iOS is a very young platform. It's already well established but the platform and the applications on the platform have a lot of growing and maturing to look forward to. Some of the tasks that are awkward and slow today will not be in the future. That doesn't help today of course.

Still Atwood's dismissal of touch computing seems extreme. Maybe he's link baiting.

Which brings us to the 'hunt-and-peck pianist'. There are many skills that make for a good programmer. Fast typing is not one of them. Atwood's analogy is plain bad.

Computer Science is no more about computers than astronomy is about telescopes.

— Edsger W. Dijkstra

This post was written on an iPad.

Defensive Threading

Designing and writing multi-threaded code is hard. Threading adds a debilitating amount of complexity to the Von Neumann architecture and, despite 50+ years of theory and implementation, the threading support in most programming languages is low level, the equivalent of malloc rather than GC managed memory.

If you’re a developer and you approach threading with trepidation then here are some experience tested guidelines and techniques that I try to follow. The overall strategy is to reduce the surface area for bugs and to increase the maintainability of the code. These are not hard and fast rules. It’s important to be pragmatic and to adjust for the specific situation.

But first, please note that I’m no expert. I’m sharing what I’ve learned and I know I’m not done learning. If this post helps you, I want to know. If you think I’ve got something wrong, I want to know. Thank you.

Avoid sharing data.

Sharing data between threads is the most common source of threading bugs. By definition many of the nastiest threading bugs can only occur when data is shared. Safely sharing data requires synchronization either in the form of a lock or an atomic primitive. Getting the synchronization right is not always easy. Avoid sharing data and the threading bug potential goes way down. As a bonus, the code can potentially run faster because the possibility of synchronization contention is eliminated.

It may seem that without sharing data, threads are pretty useless. Not so. But this is a case where you need to be willing and able to trade space for speed and safety. Give a thread it’s own private copy of everything it may need, let the thread run to completion (‘wait’ or ‘join’ on the thread), and then collect the results of it’s computations.

Avoid sharing logging.

Logging is data. See above. Sometimes the messages generated on a thread need to be reported more or less immediately. But if a delay can be tolerated, a thread can have it’s own private log that gets collected after the thread has run to completion.

When you must share, prefer lighter weight synchronization mechanisms.

I didn’t understand lock-free threading until I understood that lock-free doesn’t mean no synchronization mechanisms at all.

Under Windows the Interlocked* APIs represent atomic operations implemented by specific processor instructions. Critical sections are implemented via the interlocked functions. The interlocked functions and the critical section on Windows and the equivalent on other platforms are generally the lightest weigh synchronization mechanisms.

Technically the interlocked functions are not locks, they are hardware implemented primitives. But colloquially developers will speak of ‘locks’ and mean the whole set of synchronization mechanisms, hence my confusion over lock-free threading.

Having said that I will now forgo rigor and refer to all synchronization mechanisms as ‘locks’ because it’s pithier.

Use the smallest number of locks possible.

Don’t treat locks like magic pixie dust and sprinkle them everywhere. Synchronization locks provide safety but at a cost in performance and a greater potential for bugs. Yes, it’s kind of paradoxical.

Hold locks for the shortest length of time possible.

A critical section, for an example, allows only one thread to enter a section of code at a time. The longer the execution time of the section, the longer the window for other threads to box car up waiting for entry.

If there are values that can be computed before entering a critical section, do so. Only the statements that absolutely must be protected should be within the section.

Sometimes a value needs to be retrieved from a synchronized source, used as part of a computation, and a product of the computation needs to be stored to a synchronized destination. If the whole operation does not need to be atomic then, despite the desire to minimize locks, two independent synchronization locks could be better than one. Why? Because the source and destination are decoupled and the combined lock hold time is reduced because only the source read and the destination write are covered.

Be DRY - Don’t Repeat Yourself.

Always a good policy, being DRY has special importance with threaded code. There should be only one expression or implementation of any given synchronized operation. Every thread should be executing the same code to ensure that the operation is performed consistently.

Design to ensure that every acquisition of a lock is balanced by a release of the lock.

Take advantage of the RAII pattern or the dispose pattern or whatever is appropriate to the language and platform. Don’t rely on the developer (even when the developer is yourself) to remember to explicitly add every release for every acquisition.

Finish the threads you start.

Don’t fire and forget. Wait or join and clean up your threads and their resources.

Don’t let threads you created outlive the primary thread in the process. Some platforms have the unfortunate design of performing runtime set up and initialization, calling the the program code, and then tearing down and de-initializing on the primary thread. Other threads that may still be running after the primary thread exits may fail when the runtime is pulled out from underneath them.

Don’t kill a thread. That will leave data in an undeterminable state. If appropriate implement a way to signal your thread to finish.

Don’t get focused on locking the data when it’s the operation that needs to be synchronized.

It’s easy to get fixated on the shared data but often times the design is better served by paying more attention to the shared operations.

Avoid nested locks.

Acquiring lock A and then lock B in one part of the code and elsewhere acquiring lock B and then lock A is asking for a deadlock. No-one sets out to write a deadlock. But sometimes the code isn’t exactly what was intended or a change is made and the impact of the change isn’t fully understood. If locks are never nested then the potential for this kind of deadlock just doesn’t exist.

If locks must be nested then alway acquire the locks in the same order and always release the locks in the same opposite order. And be DRY about it.

Avoid method calls within a lock.

This may seem aggressively limiting but method implementations can change and introduce new issues like unwanted nested locks. Keeping method calls out of the scope of locks reduces coupling and the potential for deleterious side effects.

(I think of this one as following in the spirit of LoD.)

Encapsulate intermediate values.

Avoid creating inconsistent state in shared data. Operations that create intermediate values shouldn’t be performed in situ on shared objects or data structures. Use local temporaries for intermediate values. Only update the shared data with the end products of a operation.

Be careful of using the double check lock pattern.

It’s a wonderful idea that’s so clever that’s it’s broken in many languages and runtime platforms.

Where the DCLP is not just inherently broken and can be used, it still needs to be implemented correctly. Mark the variable under test as ‘volatile’ (or the closest equivalent) so that the language compiler doesn’t optimize away one of the two checks. Don’t operate directly on the variable under test. Use a temporary to hold intermediate values and wait to assign to the variable under test until the new state is fully computed.

The DCLP is often used for one time or rare initializations.

Don’t lock the ‘this’ pointer.

If there are member functions of an object that need to synchronize, create a private member variable that is used as the lock target rather than locking on ‘this’. In addition to encapsulating the locking, using a private member guards against potential issues where a framework, library, or runtime may be performing synchronization by using the ‘this’ pointer.

Explain your code.

Leave comments for yourself and the next person.

Strive to make the design grokkable.

The original design and implementation can be bug free but if the design is hard to understand and follow, bugs can be introduced in maintenance cycles. Even if you are the only developer who may ever touch the code, remember that the details of the design that are so crystal clear in your mind today will get supplanted by tomorrow’s events and miscellany like … Squirrel!

.Net Stopwatch Returns Negative Elapsed Time

The System.Diagnostics.Stopwatch class in the .Net runtime can be used to time operations. Bit there’s a problem in .Net 3.5 and earlier. The Elapsed* properties (Elapsed, ElapsedMilliseconds, ElapsedTicks) will sometimes return a negative value.

There’s a note in the documentation:

On a multiprocessor computer, it does not matter which processor the thread runs on. However, because of bugs in the BIOS or the Hardware Abstraction Layer (HAL), you can get different timing results on different processors. To specify processor affinity for a thread, use the ProcessThread.ProcessorAffinity method.

Some advocate setting processor affinity to eliminate the possibility of a negative elapsed time. But a common work-around is to simply use zero whenever the elapsed time is negative.

In recent work I used the Stopwatch class to time operations performed by Threads in a ThreadPool and I was getting false timings because of the negative elapsed time issue. I was leery of messing with the threads’ processor affinities because the ThreadPool is a shared resource. But I had concerns about the ‘convert to zero’ work-around.

Through a Microsoft contact I was able to confirm that the work-around of checking for ‘elapsed < 0’ is adequate. The negative time issue occurs only when measuring very small time periods. The issue is fixed in .Net 4.0 and the fix in the Stopwatch is to check that if elapsed < 0 then set elapsed to zero.

Will Mobile Safari be the new IE?

Apple introduced the Macintosh in 1984 and in 2007 Apple introduced the iPhone. The case has been made that with the Macintosh, Apple squandered its technological lead by maximizing profits when it should have been maximizing market share. The $99 iPhone is why 2007 won’t be like 1984.

According to TUAW, Boingo Wireless reported that for January through May of 2009 “89.2% of all mobile devices accessing Boingo’s airport hotspots” were iPhones.

TUAW: iPhone dominates Boingo airport access study

John Gruber writes about “the heart of the revolution at hand”, that mobile devices like the iPhone will supplant portable devices like notebooks.

Daring Fireball: Meg Hourihan on the iPhone as a Computer

If I speculate that ‘mobile computing’ will become more ubiquitous (not a stretch) and that the iPhone platform is already dominating in that space (open to interpretation) and if I’m developing a web site that needs to reach the mobile computing based audience, then I need to support Mobile Safari. If mobile devices become the ‘hottest’ part of the market for computing hardware and the iPhone platform becomes unequivocally dominant then Safari will be the new Internet Explorer. (Lazy or incompetent developers There will be developers who through laziness or incompetence of their own or of others will write only to Safari — but I think, given that it’s a hardware company, Apple can be a better steward of the public interest in a robust and interoperable web.)

Mad speculation? Maybe. But Flash doesn’t make the short list of technologies I plan to continue investing time and resources in learning.

Software Professionalism

One of the few cogent points to have emerged form the recent spasm of interest in so-called Software Craftsmanship is the idea that a “craftsman” has a line that they will not cross, things that they will not do. I tend to agree.

— Keith Braithwaite
peripatetic axiom: Seduced by the drama?

It’s not the point of his piece (please read his whole post) but Keith makes a nice summation.

I consider myself a software professional. My professionalism includes my skills, experience, and judgement. My professionalism is one of my assets. It is not conferred by my employer. When I change positions or jobs, my professionalism stays with me. I’m accountable for the state of my professionalism as an asset of my personal self. It is in my self interest to improve and grow but also not to perform in a manner that is harmful, destructive, or unethical as a software professional.

Raganwald and Obsession Times Voice

Daring Fireball - Obsession Times Voice
43 Folders - 43f Podcast: John Gruber & Merlin Mann’s Blogging Panel at SxSW

I continue to be inspired by Reg’s raganwald blog. Thank you Mr. Braithwaite. But Reg has moved on and is no longer actively posting to raganwald.

I miss his blog but if I’m serious about my own blog (and there’s doubt about that) then I’m glad my blog is not competing with an active raganwald (and I don’t compete with raganwald in any literal sense.) In the audio of Mann and Gruber’s talk, Merlin says something like your blog needs to be better than 80% of the other blogs that are focused on the same obsession. I recall Scott Adams, creator of Dilbert, writing that he greatly admired Gary Larson’s The Far Side and Bill Watterson’s Calvin and Hobbes and was consequently very glad when those strips ceased and ‘left the field.’

My blog, this blog, is not raganwald but like John Gruber’s New Yorker, it is a point of inspiration.

Now go read raganwald and see what you missed.

Software Design is not Quantitative

The most contentious point between software engineering culture and visual design culture is the question of whether important things can be always seen in absolutes. The engineering approach values measurable, reproducible results which can be represented in a graph or a checklist. Unit tests and benchmarks illustrate progress.

[…]

Visual design is often the polar opposite of engineering: trading hard edges for subjective decisions based on gut feelings and personal experiences. It’s messy, unpredictable, and notoriously hard to measure. The apparently erratic behavior of artists drives engineers bananas. Their decisions seem arbitrary and risk everything with no guaranteed benefit.

— Scott Stevenson
Theocacao: Measuring the Design Process
(writing about Doug Bowman’s stopdesign : Goodbye Google)

Software design is not data-driven engineering. Unit tests and benchmarks are about testing an implementation and certainly what’s learned needs to feed back into and inform the design but strictly speaking these are not design activities. There is a myriad of decisions in a software design that are made on qualitative grounds, not quantitative data. Maybe Google tries to make even those decisions driven by data. I’d like to know if it’s so. Most places I’ve worked there was someone with a bigger paycheck and the word ‘architect’ in his/her job title who was expected to pass judgement on the software design. Generally this person did so based on her/his skills, knowledge, and experience. A visual designer who’s aware of that may be all the more vexed when asked to defend the choice of pixel width for a border with data. Where’s the supporting data for the choice to use MVC? How come the debate over WS-* versus REST hasn’t been agreeably resolved with a graph?

If something is a ‘religious debate’, like choice of text editor or choice of programming language or choice of OS, does that mean it’s a question that is not (currently) answerable with data? Or does it mean there are different values and needs and experiences, qualitative things, that lead to different answers?

There’s all kinds of inexact unpredictable squishy messy issues, questions, and decisions that go into software development even without considering the visual interface. Scott is right on when he says:

Data and measurements are essential in software, and can take you a long way on their own. But feelings and instincts are necessary too if you want to do something remarkable.

The Only Way To Improve Software Is To Change It

One place I worked had a major release of their enterprise software and following the release a bug appeared. A serious bug. The business was not happy. The Director of Software Engineering was under pressure. The bug had never been reported before and the system processed a large volume of activity every day and had done so since the last major release six months ago. The Director was confident the bug was introduced with the new release. Because of the sense of urgency he didn’t wait for a full analysis. He made the decision to rollback to the prior version. But he was wrong. Rolling back didn’t fix the issue. The bug was pre-existing. It was unfortunate timing that the first time conditions were right to trigger the bug was the day after a major release.

People sometime refer to software as ‘hardening’ in Production. There’s a pervasive presumption that working Production software is generally safer and less risky than newly developed software. The idea is that the longer the software has been in use in Production without change the less likely it is to have unknown bugs. But hardening is a misnomer. Software doesn’t cure like concrete.

The assumption behind ‘hardening’ is that Production is the ultimate test. That the volume and variety of a Production environment is more comprehensive than any test regimen could be. But how good of a test is Production? What if 80% of typical Production activity exercises only 20% of the code? What happens when the unusual occurs? Many organizations test for load and scale issues but I don’t hear of organizations commonly measuring (or inferring) code coverage in Production. Could the unit tests and QA tests actually be more comprehensive than typical Production scenarios? Could ‘hardening’ represent an unsafe assumption?

A colleague pointed out there can also be an anthropomorphizing factor at work. Who do you trust more — the new recruit or the veteran? Even with known flaws the veteran can seem like a safer choice than the unknown recruit. “The devil you know is better than the devil you don’t.” But software releases are not people and you may not know the devil you know as well as you think you know it.

Program testing can be used to show the presence of bugs, but never to show their absence.

— Edsger W. Dijkstra

I once wrote the Dijkstra quote on a whiteboard as part of a presentation. The technical folk in the room nodded in recognition and agreement. The non-technical manager became agitated and vehemently disagreed.

To manage risk an organization working with the supposition that ‘hardened’ Production software is safer, may place strict controls on Production releases. Because of the effort involved in a release, releasing quarterly may be considered a fast schedule. Because of the amount of time between releases, each release tends to be large which increases the perceived risk.

If the potential for regression issues can be minimized (say through automated unit tests), which becomes the greater risk — introducing new bugs with a new release or not fixing latent bugs in the existing Production code? If the risk is in not releasing, than releases need to happen faster. Instead of quarterly what if releases were biweekly? The work would be chunked into smaller more frequent releases. Bugs which aren’t critical enough to require a special immediate fix could be fixed in production in 2 weeks instead of 3 months. The software could potentially adapt more quickly to changing needs and user feedback.

Build unit tests. Release often. The only way to improve software is to change it.

Hacking SLN Files to Improve Visual Studio/Visual Source Safe Integration

There are some who think Microsoft Visual Source Safe (VSS) is great. There are some who think that it’s not great but it is pretty good. And there are some who think Source Safe is just good enough. I am not among any of those groups.

One pain point with Source Safe in a Microsoft tool chain is integration with Visual Studio. Historically Visual Studio has stored source control information directly in the solution and project files. This reveals itself to be a really terrible idea the first time a project or solution file is shared in Source Safe. Checkouts from within the IDE will use the the source control bindings in the solution or project. If the solution or project file has been shared and not changed the bindings will be pointing to the original location in Source Safe. Checking out through Visual Studio will checkout the wrong file.

Yes, the solution and project files can be branched and the bindings updated. That’s sub-optimal. It means branching just to fix a tool problem and not because of any actual divergence in the code base. Any non-divergent changes to the solution or project must then be manually propagated to all the branched versions. Ugh.

The problem has not gone unnoticed at Microsoft. Over time and new releases of VStudio and VSS, improvements have been made.

My current position of employment is not using the latest and greatest. We’re on Visual Studio 2005 and Visual Source Safe 2005. The code base is in C#. I worked out a way to have shared solution and project files for non-web projects. Web projects in 2005 are different beasts and don’t follow the same rules. If you are using different versions of Visual Studio or Visual Source Safe your mileage will vary.

When getting files from VSS into a working directory, Visual Source Safe 2005 will create or update a mssccprj.scc file if any of the files present include a solution (.sln) or project file (for C#, .csproj). The mssccprj.scc file is a text file and it will contain the VSS bindings for the solution and project files that are in the same directory as the mssccprj.scc file.

In Visual Studio 2005, project files by default use the special ‘SAK’ string in the project file settings for VSS bindings. SAK indicates to Visual Studio that the bindings in the mssccprj.scc file should be used. The mssccprj.scc bindings are based on the directory retrieved from Source Safe. This means that shared project files just work. Yay.

In 2005 the problem is with solution files.

More specifically the problem is with solution files that include project files that are not in the same directory as the solution file. Creating a MyHelloWorld project will create a MyHelloWorld.sln and a MyHelloWorld.csproj in a MyHelloWorld directory. The .sln will reference the .csproj by name only and both files will have bindings in the mssccprj.scc file in the same directory and that all works without issue. But create a blank solution and add multiple existing projects to it and Visual Studio 2005 reverts to storing specific VSS bindings for the projects in the solution file.

There’s a work-around but it doesn’t work for parenting paths. Any time a solution references a project where the path to the project file starts with ‘..’, Visual Studio will revert to storing a VSS binding in the solution file. Because of this limitation it becomes convenient to have a convention that solution files generally go in the root of the code base tree.

The goal is to get the VSS bindings out of the solution file and have Visual Studio rely on the mssccprj.scc file. I haven’t found a reliable way to do this from within the IDE with existing projects but the solution (.sln) files are just text files, so I hack them.

Here’s a snippet from a .sln file. In Source Safe, the solution file is in “$/CodeBase v1”. There are two projects: a class library and a windows application. The SccProjectName<N> values are bindings to specific locations in the source safe repository. These are the bindings that need to be removed.

Global
	GlobalSection(SourceCodeControl) = preSolution
		SccNumberOfProjects = 3
		SccLocalPath0 = .
		SccProjectUniqueName1 = ClassLibrary1\\ClassLibrary1.csproj
		SccProjectName1 = \u0022$/CodeBase\u0020v1/ClassLibrary1\u0022,\u0020TAAAAAAA
		SccLocalPath1 = ClassLibrary1
		SccProjectUniqueName2 = WindowsApplication1\\WindowsApplication1.csproj
		SccProjectName2 = \u0022$/CodeBase\u0020v1/WindowsApplication1\u0022,\u0020WAAAAAAA
		SccLocalPath2 = WindowsApplication1
	EndGlobalSection

The .sln file can be edited to remove the SccProjectName<N> values but the SccLocalPath<N> must be updated to ‘.’ and a new property, SccProjectFilePathRelativizedFromConnection<N>, must be added with the old local path value and an appended directory separator.

Global
	GlobalSection(SourceCodeControl) = preSolution
		SccNumberOfProjects = 3
		SccLocalPath0 = .
		SccProjectUniqueName1 = ClassLibrary1\\ClassLibrary1.csproj
		SccLocalPath1 = .
		SccProjectFilePathRelativizedFromConnection1 = ClassLibrary1\\
		SccProjectUniqueName2 = WindowsApplication1\\WindowsApplication1.csproj
		SccLocalPath2 = .
		SccProjectFilePathRelativizedFromConnection2 = WindowsApplication1\\
	EndGlobalSection

Reference: Alin Constantin’s blog: The SAK source control strings in Visual Studio’s project files