 |
| Ken Thompson |
I was reading through bits of the excellent Coders at Work book by Peter Seibel and found it interesting that the (what I'd call respectfully) old school developers, such as Ken Thompson, Joe Armstrong and Jamie Zawinski use hardly any modern tools and techniques while developing software.
Ken Thompson was the designer of the B programming language (the precursor to C) and also the Go programming language (with Rob Pike). He also worked alongside Dennis Ritchie to develop the C programming language and the original Unix operating system while working at Bell Labs. After designing the UTF-8 method of character encoding on a placemat in a New Jersey diner, he worked overnight to implement full UTF-8 support in Bell Lab's Plan 9 operating system. Regarding his programming style, he debugs only via printf statements, hardly ever uses unit tests, starts his projects by designing the data structures and then works bottom up, with throwaway test stubs.
 |
| Joe Armstrong |
Jamie Zawinski worked in MIT's AI lab with Lisp, then moved onto leading the development of Lucid Emacs, also in Lisp, which later became known as XEmacs. After this he joined Netscape and worked on the front-end for the Unix version of Netscape Navigator, and later led the development of Netscape Mail (both projects were in C). He too prefers to just use print statements to debug his code. His process is either to write code top down or bottom up, let the code evolve naturally, then refactor it when necessary. During development he hardly ever uses unit tests, believing it slows things down - he thinks there's a lot to be said for getting the code right first time. In his view, its a matter of priorities, "do you want this to be good software or do you want it to be done next week - pick one because you can't have both".
 |
| Jamie Zawinski |
So what tools and techniques do you actually need to be a great programmer? Are these modern techniques of TDD, BDD, Scrum, Agile, Design Patterns, XP etc. just window dressing or do they serve a higher purpose? Is it just a fact that a gifted programmer will always find a way to be a great programmer, no matter what tools he or she works with?
My own view is that some level of TDD and a reliance upon a decent set of unit tests is invaluable. Maybe then these modern techniques should just be seen as advances to make our job a little easier and more productive, especially for those who are not a genius-level developer, like these guys.
Follow @dodgy_coder
Subscribe to posts via RSS
You might be interested in this paper from Alistair Cockburn:
ReplyDeletehttp://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development
It describes how he discovered that tools and methodologies are pretty much incidental to the success of a project, and that project success is much more dependent on the people involved and how they work.
Interesting article, thanks - here's the clickable link for others to read ... "Characterizing people as non-linear, first-order components in software development"
Deleteand now people use coffeescript and have boat loads of bugs introduced by shitty features like implicit returns hahahhaha
ReplyDeleteImplicit returns, like in Erlang (Joe Armstrong's language), Haskell (which he apparently uses), Lisp?
DeleteIf you introduce bugs because of your poor understand of a language, and are ignorant enough to think implicit returns are a new/bad idea, I can just imagine the boat load of bugs in your code.
While these gurus are (possibly) good enough to debug with print statements and go without unit tests, do they advocate the same for others?
ReplyDeleteWhen you try to work with people that are not so bright (i.e. basically everybody else!) and you'll soon realise you need recipes to put some order in the creative chaos.
So - while Unit Tests, etc. etc. are most definitely NOT necessary to write code, they ARE necessary to have a maintainable code base in the medium/long term (e.g. by mere mortals!) .
Good point. I agree that for mere-mortals (like you and I), unit tests are very necessary, especially to be able to maintain and refactor existing code.
DeleteWhile they may be geniuses, that is not the REASON they choose to avoid modern development tools, techniques.
ReplyDeleteI wasn't suggesting that they are deliberately avoiding using modern tools/techniques - in fact when all of these guys were doing their most productive work, things like TDD, OO, IDEs and BDD weren't known about yet. I just wanted to make the point that these guys managed to be extremely successful in the projects without using modern techniques.
DeletePersonally I think the need for using IDEs is due to (a) not understanding what you are actually doing or (b) uaing something that is too complex to wrap your mind about.
ReplyDeleteCase (a) occurs when you start writing, lets just take it as an example, Java with little to no knowledge of the language. You create something and as you go along you continually need to refactor due to changing insight in where your code is going. Instead of thinking upfront about what you are doing and what a proper design is.
And for (b) something that comes to mind is all those frameworks with a bazillion XML files that then interact with the code in mysterious ways. Without an IDE it becomes hard to get an overview of what is going on.
Personally I write in Java, C, C++ and Erlang and I use (GNU) Emacs to write all this code, relying on build systems like maven, make and rebar to perform the compilation of the code. I do use unit tests because they help me validate the working on the code, but only on an integration level, so that it validates the code and not every single line of code. The thing I like most about this is that my editor always works the same, no matter what language I use.
HTH,
Arjen
Thanks for your comments. There's a lot to be said for using the same editor such as Emacs all the time - you can become very efficient with it, and it can also be used across all platforms; linux, mac, windows. Personally I started off using plain text editors, but after the last few years of using mainly the Visual Studio IDE, I now find it difficult when I need to go back to editors which don't have at least some level of code completion (intellisense). The thing where it helps me enormously is when using libraries - there's an immense amount of libraries/modules out there these days, especially in the frameworks for .NET and Java.
DeleteI'm an old school developer because I learned programming before IDEs, unit testing, OOP, Agile, etc. Computer time was expensive and memory was precious when I was learning. I formed habits such as walking through my code and desk checking because I had to wait a long time between runs of my code. I was heavily influenced early in my career by Unix and C, which emerged just as I was starting to program professionally. The practical style espoused by Ken Thompson, Dennis Ritchie, Brian Kernighan, and Rob Pike emphasized choosing suitable data structures and writing simple, efficient code. I learned vi back when my "workstation" was a VT-100 terminal and still use it every day.
ReplyDeleteA lot of what is touted as new in software development turns out to be an old idea with a new coat of paint. Programmers can be quick to fall in love with shiny new things and fail to study the history of their craft, leading to a cycle of re-discovery and re-invention that ultimately wastes time. New tools and methodologies aren't all bad but they can distract programmers from the task of programming.
Thanks for your comments. I agree with your point that writing simple and efficient code (in terms of both memory and CPU usage) is something that is widely undervalued. I think the perceived bloat of modern languages (C++, Java, C#) and frameworks is something that horrifies a lot of old school devs who were brought up to write code within the limits of machines of the day, e.g. less than 1MB of RAM @ 50MHz. These days that wouldn't even get you a basic screensaver.
DeleteI found it interesting that these developers listed (Thompson, Armstrong & Zawinski) have the view that C++ is a bloated horrible language to be avoided at all costs. They all favoured C over C++. This is the polar opposite of many developers, who often hold the view that C++ is the leanest and most efficient language out there.
I don't think that picture is of jwz.
ReplyDeleteIts taken from this 2011 video on the computer history museum... Jamie Zawinski: The Art of Programming, It's About Style
DeleteAs programming goes more mainstream, the quality of the average developer drops. Newer paradigms protect large code bases and teams from the unmanageable complexity developers are dealing with. It's a shame, but just look at the average programmer job now: Several years experience of Java or C# in a large team. Managed languages with strict guidelines in place to ensure that damage is minimized by bad programmers. Large projects are divided into awkward components that are bashed together until they work.
ReplyDeleteThis is terribly inefficient compared to the small, highly skilled teams we admire from the 70s and 80s, but it's necessary. There are only so many such developers to go around, the more mundane tasks need to be done by less enthusiastic employees.
Good observations, I've seen this lack of enthusiasm myself on teams. The other factor is the difficult and less rewarding job of software maintenance as opposed to greenfields development. Interesting that these three old school devs all came from research backgrounds but ended up contributing to what later became big commercial successes - Unix/Erlang/Netscape. They were also fundamentally driven by challenges, with a deep interest in programming and learning new things. I think Joe Armstrong mentioned that he reserves 20% of his time for solely learning about new technologies.
DeleteI, myself, do not use unit tests much, and I really agree with the quote: "do you want this to be good software or do you want it to be done next week - pick one because you can't have both". I find it much easier to test pieces of code in isolation while designing them, via a more 'manual' method, and then leave that piece of the code alone. If it needs to be changed again, then I do manual testing again.
ReplyDeleteIntegration testing, however, is as credmp wrote an entirely different matter. But even there I am often at a loss because designing reasonably comprehensive integration tests can often be completely unfeasable; what if, for instance: the underlying code is dependant on a massive amount of memory, or worse yet, it's non-deterministic?