LinLog

In recent years, I've been reading a lot more e-books. However, I've tended to stay away from PDFs and other non-proprietary formats when I could. This is weird, because it's the opposite of my usual preference.

The reason is, quite simply, convenience. The Kindle and Nook apps are free, easy to use, and offer good (or, at least, sufficient) support for the two things I care most about: text zooming and synchronization.

While changing text size is a basic feature for mobi and epub most readers, it's awkward for PDFs because they do page-based text layout. So you can zoom in on a page, but it's not generally possible to change the font size and reflow the page, which makes reading less pleasant - particularly on a phone. Now, if you have a 10-inch tablet, that's not really an issue, as the real size of the text will be about what you'd get in a physical book.

This leads to the second feature: synchronization. Sometimes you just don't want to carry a tablet around. But if you find yourself waiting for something, it would be nice to read your book. And since you always carry your phone, why not read on that? It may not be as good, but it's fine for 15 minutes here or there. And the proprietary apps are great for that. But DRM-free e-books, not so much. You can always use a file synch app to get copies of them, but syncing the last read page is a different question.

It turns out that Readera Premium now has me covered on that. I've been using the free version for a while, but never really needed the premium features. However, it looks like they recently added file and progress sync via Google Drive to the list of premium features. This alone was enough to make me she'll out the $11 for it.

So far it works pretty well. When I fired up the premium version on my tablet, it searched for files on my device and created.a library. Unfortunately, many of the files it "found* were phantoms - they'd long since been deleted, but for some reason Readera thought they existed. Apparently this is an artifact of how they scan the device. The main issue was that this seemed to interfere with the sync. I removed those and was able to sync the handful of real files I cared about.

Next step: install and run the premium version on my phone. It went through the same scanning process, adding the local files to my library, but no sync problems this time. And best of all, I was able to open up the PDF book I'd been reading on my tablet and it opened to the correct page!

So now I can read any book anywhere. That'll be nice for books like the one I'm reading now, which is out of print and not available on the commercial platforms. I'm not crazy about it using Google Drive (as I don't use that for anything else), but for progress sync, I'll take it.

You know you're getting obscure books when even Goodreads doesn't know what the heck you're reading. Or maybe it's less that it's "obscure" than that it's "old".  And French.  It's hard to tell.

In this case, the book in question is "The Nature of Hinduism" by Louis Renou.  This is a book that's been sitting on my bookshelf for literally years.  I'm not even completely sure where it came from.  It has labels from the local high school library, so it apparently originated there.  I think either I got it at the public library's book sale, or it was left in our house and I found it when we moved in.

Anyway, Goodreads had no idea about this book.  It had a handful of entries for the author, but that's it.  So I had to add it to Goodreads.

This endeavor started off poorly because I decided to do it on my phone.  It turns out that the Goodreads mobile app doesn't actually have a way to add new books.  Neither does the mobile website.  The app has a feature to scan the barcode, but this book is 50 years old - it doesn't have a barcode.

If you want to add a book, you need to use the desktop site, which is a pain when you're using a mobile device.  Of course, once you're on an actual computer, it's pretty easy.  There's a "Manually add a book" link right on the search results page and it's fairly easy from there.  Some of the fields on the add form are a bit obscure, but most of them are optional anyway, so it's not a big deal.

I must admit I'm a little curious as to how much use the "manual add" page actually gets.  I'm sure it's not the most commonly used feature by any stretch of the imagination, but I would have expected it to be common enough to merit a link on the mobile site, if not the app.  Am I the only person left who reads used books that old?  That seems depressing.  Perhaps it's just that people who read old books tend not to use Goodreads.  I can only hope.

This is my more-than-slightly belated birthday post.

This year, my birthday fell on the last day of our vacation in Cape Cod.  We've been there several times, so we've seen most of the attractions we're interested in at least once.  Thus we had a nice, restful, laid-back week.

I'm not usually much for shopping, but one of my traditional activities on the cape is to go shopping for used books.  (Actually, I do that pretty much everywhere.)  However, this year I was very disappointed to find that my favorite used book shop on Main St. in downtown Hyannis had closed! I'd shopped there every time we've been to the cape and they had a really nice selection.  I define a "nice selection" at a used book store as one that includes a wide range of unusual books on a wide variety of topics (such as this one, which I bought at that shop two years ago and spent my vacation week reading), as opposed to used book stores that carry mostly mass-market paperbacks, usually in the mystery and romance genres.  

Fortunately, I was able to find another good used book shop - Parnassus Book Services in Yarmouth.  We always stay in Hyannis, so it's not as convenient as the other one was, but they've got a great selection.  In fact, it's a bit daunting - the shelves literally go up to the ceiling and they're completely packed.

Yet even with the abbreviated browsing time I had when shopping with a small child, I still managed to find several interesting volumes, including:

1. Islam by Karen Armstong
2. A History of the Vikings by Gwyn Jones
3. The Book of J by Bloom and Rosenberg
4. Dinosaur Lives by John Horner
5. Aristophanes' The Forgs
6. Exodus: The True Story by Ian Wilson 
7. Discovering Dinosaurs by Norell, Gaffney, and Dingus
8. Fundamentals of Elcetronic Data Processing: An Introduction To Business Computer Programming, edited by Rice and Freidman

As you can see, my book tastes are a bit eclectic.  Two themes that are obvious are my interest in studying religion and Dinosaurs.  The former is a legacy of my BA in Philosophy, while the latter is a result of being the father of a six-year-old boy - I loved dinosaurs when I was young too, and my son's interest in them re-sparked mine.

I couldn't resist the one on the bottom, though: Fundamentals of Electronic Data Processing: An Introduction to Business Computer Programming.  It's from the 1960's, so basically a piece of computing history.  I've got a couple of other computing books of similar vintage sitting on my shelf, though this is certainly the oldest.  One of these days I'll have to read them all the way through and write up some reviews, like I did with my copy of The Mythical Man-Month.  It's always interesting to see just how much has stayed the same despite the radical changes in technology.

This is part two of my evaluation of the Personal Software Process.  This time I'll be talking about the actual process of learning the PSP.  In case you haven't figured it out yet, it's not as simple as just reading the book.

Learning the PSP

The PSP is not the easiest thing to learn on your own.  It's a very different mindset than learning a new programming language or framework.  It's more of a "meta" thing.  It's about understanding your process: focusing not on what you're doing when you work, but rather how you're doing it.  It's also significantly less cut-and-dried than purely technical topics - not because the material is unclear, but simply because what constitutes the "best" process is inherently relative.

Given that, I suspect the best way to learn the PSP is though the SEI's two-part training course.  However, I did not do that.  Why not?  Because that two-part course takes two weeks and costs $6000.  If you can get your employer to give you the time and shell out the fee, then that would probably be great.  But in my case, that just wasn't gonna happen and the SAF (spouse acceptance factor) on that was too low to be viable.

Instead, I went the "teach yourself" route using the self-study materials from the SEI's TSP/PSP page.  You have to fill out a form with your contact information, but it's otherwise free.  These are essentially the materials from the SEI course - lecture slides, assignment kits, and other supplementary information.  It's designed to go along with the book, PSP: A Self-Improvement Process for Software Engineers, which serves as the basis for the course.  Thus my learning process was simply to read through the book and do the exercises as I went.

(As a side-note, remember that this is basically a college text-book, which means that it's not cheap.  Even the Kindle version is over $40.  I recommend just getting a used hardcover copy through Amazon.  Good quality ones can be had for around $25.)

Fair warning: the PSP course requires a meaningful investment of time.  There are a total of ten exercises - eight programming projects and two written reports (yes, I did those too, even though nobody else read them).  Apparently the course is designed around each day being half lecture, half lab, so you can count on the exercises taking in the area of four hours a piece, possibly much more.  So right there you're looking at a full work-week worth of exercises in addition to the time spent reading the book.

Personally, I spent a grand total of 55 hours on the exercises: 40 on the programming ones and 15 on the two reports (for the final report I analyzed not only my PSP project data, but data for some work projects I had done using the PSP).  While the earlier exercises were fairly straight-forward, I went catastrophically over my estimates on a couple of the later ones.  This was largely due partly to my misunderstanding of the assignment, and partly to confusion regarding parts of the process, both of which could easily have been averted if I'd had access to an instructor to answer questions.

Tools

 As I mentioned in the last post, you'll almost certainly want a support tool, even when you're just learning the PSP.  Again, there's a lot of information to track, and trying to do it on spreadsheets or (God forbid) paper is going to be very tedious.  Halfway decent tool support makes it manageable.

I ended up using Process Dashboard, because that seems to be the main (only?) open-source option. In fact, I don't think I even came across any other free options in my searches.  I understand other tools exist, but apparently they're not public, no longer supported, or just plain unpopular. 

One of the nice things that Process Dashboard offers is the ability to import canned scripts based on the PSP levels in the book.  To use that, you have to register with the SEI, just like when you download the PSP materials, which is annoying but not a big deal.  (The author got permission from the SEI to use their copyrighted PSP material and apparently that was their price.)  This is really handy for the learning process because it puts all the scripts right at your fingertips and handles all of the calculations for you at each of the different levels.

In terms of capabilities, Process Dashboard is actually pretty powerful.  The UI is extremely minimal - essentially just a status bar with some buttons to access scripts, log defects, pause the timer, and change phases.  Much of the interesting stuff happens in a web browser.  Process Dashboard runs Jetty, which means that it includes a number of web-based forms and reports that do most of the heavy lifting.  This includes generating estimates, entering size data, and displaying stock and ad hoc reports.

Process Dashboard has fairly extensive customization support, which is good, because one of the basic premises of the PSP is that you're going to need to customize it.  You can customize all the process scripts and web pages, the project plan summary report, the built-in line counter settings, the defect categories, etc.  And that's all great.  The one down side is that the configuration is usually done by editing XML files rather than using a graphical tool. 

Since this is an open-source developer tool, I guess that's sort of fine.  And at least the documentation is good.  But it's important to realize that you will need to spend some time reading the documentation.  It's a powerful tool and probably has just about everything you need, but it's not always easy to use.  On the up side, it's the sort of thing that you can do once (or occasionally) and not have to worry about again.  Just don't expect that you'll be able to fire up Process Dashboard from scratch and have all the grunt work just done for you.  There's still some learning curve and some work to do.  But if you end up using the PSP, it's worth it.

As I mentioned in a couple of previous posts, I've been studying the PSP.  As promised, this is my first report on it.  After several failed attempts to write a single summary of the process, I've decided to divide my assessment up into a series of posts.  This first entry will be a basic overview of what the PSP actually is and how it's intended to work.

What is the PSP?

PSP stands for Personal Software Process.  It was developed by Watts Humphrey of the Software Engineering Institute (SEI) at Carnegie-Mellon University (which you may know as the home of CERT). Humphrey is also the guy who came up with the Capability Maturity Model, which is the CMM in CMMI.  His intent was to take the industrial-strength process methodologies he worked on for the CMM and scale them down to something that could be useful to an individual developer.  The result is the PSP.

Despite the name, at its core the PSP isn't actually a development process itself.  Rather, it is a process improvement process.  To put it another way, the goal is not to tell you how to develop software, but rather to give you the intellectual tools to figure out the development process that works best for you and help you improve that process to make yourself more effective.

Now, to be clear, Humphrey actually does describe a particular development process in his PSP books.  And yes, that process is kind of "waterfally" and extremely heavy.  And if you look for PSP information online, you'll no doubt find a lot of people who take issue with that process.  And they're right to.

But try not to get hung up on that.

As Humphrey puts it, the process he describes is his process.  That doesn't mean it should be your process.  The process he describes is for pedagogical purposes as much as anything else.  It is intended to demonstrate the kinds of methods that apply to large-scale industrial systems, so that you have those tools in your toolbox if you need them.  If this process doesn't really work for you (and it almost certainly won't), then you should modify it or replace it with something that will work for you.

This is something that bears dwelling on.  Although pretty much all of the PSP focuses on Humphrey's process, he notes several times that it is important to pick a process that's sustainable for you.  To put it another way, it's important to be realistic.  Sure, his process might be objectively "better" by some measure than whatever you're doing, but that doesn't matter if you aren't going to follow his process.  Maybe his process conflicts with your company's process; maybe it's not effective for the kind of project you usually do; maybe you just plain don't have the will power to stick to it.  It doesn't matter.  The process you define needs to be in line with what you actually do, otherwise it's not going to help you.  So while you can learn from Humphrey's process, don't take it as gospel and don't think "this is what I need to be doing."

For me, the real take-away of studying the PSP is to be mindful of your development process and constantly try to improve it.  The goal is simple: quality and consistency.  Monitor your process and tune it such that you can consistently build a quality product in a predictable time-frame.  Ground yourself in reality and be guided by the data, not the latest fads.

The PSP Approach

The PSP is all about data-driven process changes.  As you work, you collect data on what you produce. The general idea is that you analyze that data and make changes to your process based on that analysis.  You then repeat this process, evaluating the results of your changes and making further tweaks as necessary.  So it's basically a plan-do-check-act cycle.  This is the same sort of thing that agile methods advocate (e.g. Scrum retrospectives).

Project Structure

The PSP structures a task or project into phases.  The exact phases will obviously depend on your particular process.  The "standard" (i.e. from Humphrey's process) phases are Planning, Development, and Postmortem.  In the Planning phase, you define what is to be built and construct estimates of the effort involved.  The Development phase is where you actually construct the software.  In the standard PSP process, this is divided into a number of sub-phases, depending on which level of PSP you're using.  Lastly, the Postmortem phase is where you record your final process measurements and document any problems and potential process improvements that came up in the course of the project.

The PSP levels I mentioned above are essentially maturity phases.  In the process of learning the PSP, you go through six of them: PSP0, PSP0.1, PSP1, PSP1.1, PSP2, and PSP2.1.  You start with PSP0, which is basically just "whatever you do now, but with measurements" and progress up to PSP2.1, which includes five sub-phases: Design (with standard design templates), Design Review, Code, Code Review, and Test.  I'll analyze this structure and the contents of the phases in a later post. 

Data Collection

Data collection in the PSP happens at a very fine-grained level.  The idea is that you do light-weight data capture as you work in order to minimize inaccuracies.  Data is collected on three axes: how much time is spent in each phase of the project, size of the product, and what defects were found.  In the standard process, you would track how many minutes you spend in each phase or sub-phase, how many lines of code you add or modify, and the number and type of bugs you find in in each phase.

The general idea behind this is simply that the more detailed the data, the more opportunities you have to use it later on.  The PSP suggests a number of ways to use this data to drive and measure process change.  Two of the most visible are the use of historical size and time data to drive the estimation process and the use of defect phase, type, and time data to measure the efficiency of defect removal activities such as code review and testing.

Interestingly, when Humphrey started developing and teaching the PSP, students tracked this stuff on paper.  He later introduced spreadsheets to track it, which is better, but still a little clumsy.  These days, there are PSP support tools you can use.  The main open-source one seems to be Process Dashboard, which I used from day one.  It will help you track PSP data and do most of the calculations you need for data analysis.  Frankly, I can't imagine trying to track this by hand or with Excel spreadsheets - it just seems like it would be painfully tedious.  But with decent tool support its really not that bad.

Quality Management

One of the interesting things to note about the standard PSP process is that it explicitly takes a position on quality management.  This is something you don't tend to hear a lot about - in fact, it might not even have occurred to you that quality is something you can manage.

The position Humphrey takes is simple: the right way is always the fastest way.  And the right way is to get things right the first time to the maximum extent feasible.  That means finding defects as early as possible and taking steps to stop them from being injected in the first place.

I'll get into the details of this in a later post.  I mention it now simply Humphrey devotes a lot of ink to it.  In fact, much of the new material in the higher PSP levels is devoted to quality control.  Quality management is one of the big uses of the defect data that you track as part of the PSP, so it's important to realize at the outset that this is a core part of the process.

Should I Care?

I think you should.  You may not want to actually use the PSP, but it's still an interesting thing to learn about.  If you're like me, you probably never thought about how you build software in terms of hard data, so it's interesting to see how it can be done.  It's a very different and empowering way of understanding how you work - it makes programming feel more like a science and less like a black art.  So even if you don't want to go all the way and actually try to use the PSP, it's enlightening to read about the various statistical analysis techniques and quality improvement recommendations.  If nothing else, it broadens your perspective and gives you more intellectual tools to draw on.

In part two, I'll talk a little about what I did to learn about the PSP, including the resources and tools that I used.

I've been writing software for a living for the last 15 years.  I've been doing mostly full-stack web development for nine of those.  That means I've written my fair share of JavaScript code.  But you know what?  It turns out I really don't know JS.  I thought I did.  But I don't.

I reached this conclusion after reading the first two and a half of the six books in Kyle Simpson's You Don't Know JS series.  Normally, I'd wait until I was finished with the series to blog about it, but seriously, this is good stuff.  If you think you have a decent grasp of JavaScript, you should read this to test your mettle.

Forget the W3Schools tutorials or jQuery guides you might have read to learn JavaScript in the first place.  This is way beyond that.  The goal of the You Don't Know JS series is not to teach you "how to code JavaScript" but rather to help you master JavaScript.  It's a deep-dive into the guts of JavaScript - not the subset most of us are used to, but what's actually spelled out in the ECMAScript specifications. 

The beautiful thing about this series is that it's not about expanding your catalog of technical tricks.  Most of it (well, of the 2.5 books I've read so far, anyway) is about understanding the fundamentals in a deep way.  For example, going beyond "oh, this in JavaScript is weird" and actually understanding the rules behind how the dynamic binding of this works and how it differs from the lexical scope used for everything else.  Things like that are easy to gloss over.  After all, you don't really need to know the gory details of how this is bound in order to write code and be productive.  But these kinds of things really are important.  They're the difference between "knowing" JavaScript and knowing JavaScript. 

To put it another way, there's more to the craft of building software than just "getting the job done".  For some people, just "getting it done" is sufficient - and that's fine: they're satisfied to remain journeymen.  But for some people, that's not enough - they want to be master craftsmen.  This series is for them.

As I mentioned in my a previous post, I've been doing some reading around process.  A development process is one of those things that you always have, by definition.  It might be ill-defined and chaotic, and you might not even thingk about it, but eventually you go through some process to develop code.  But when you think about it, this process is going to have a not insubstantial impact on the quality of the software you produce.  After all, how could it not?

However, as developers, we often think of "process" as a dirty word.  It's one of those bureaucratic things imposed on us by pointy-haired project managers, with their Gantt charts and their Microsoft Project.  Sure, those highfalutin "processes" sold by over-priced consultants might be useful for those huge, soulless "enterprise" shops that have thousands of know-nothing drones cranking out Java ports of mainframe COBOL systems.  But we don't need those!  We're "code poets", "10x developers", "coding ninjas", etc.  We can code circles around a dozen of those enterprisey jokers in our sleep! 

Except it doesn't really work that way.  Even if you accept the notion that the best developers are ten or more times more effective than average ones, they still have to deal with the complications of ill-defined features, requirements changes, integration problems, performance problems, communication between stake-holders, and the myriad other issues that emerge and magnify as more people become involved in a project.  If you expect to make it through any decent sized project and not have it turn into a hot mess, you have to have some way of managing all the things that come up. Some organizations, such as the aforementioned Java-drone shop, do that by implementing processes that require mountains of paperwork that serve primarily to cover everyone's butt.  Others take the agile approach.

If you've been living in a cave for the past decade or so, the "agile" movement is a response to the stereotypical "big, up-front" processes of old.  The values of the agile community are summed up in the Agile Manifesto, but the basic idea is to focus less on the bureaucratic paper-pushing and more on delivering what the customer needs.  This generally sounds good to developers because it means less time spent on TPS reports and more time actually building software.  And it sounds good to managers because the iterative nature of agile development means you get the software faster (for certain definitions of "faster").  And it sounds very good to consultants who can offer agile training and certification.  So, naturally, everyone is talking about it.

That's where Bertrand Meyer's book Agile!: The Good, the Hype, and the Ugly comes in.  Its stated purpose is to separate the wheat from the chaff; that is, to pick out what's good about agile methods and what can be safely disregarded.  Meyer says it is intended as an even-handed and fact-based assessment to offset the hyperbole that often surrounds discussions of agile.

Part of what attracted me to this book was simply the fact that it's by Bertrand Meyer.  I first became aware of his work when researching for my Masters thesis.  He's probably best known as the originator of the idea of "design by contract" and Eiffel, and has a strong footing in formal methods, which is not usually the type of thing you'd associate with agile.  In fact, some people might consider it the opposite of agile.

Overall, I found the book not only enlightening, but also highly entertaining.  Meyer writes in an informal and even playful style.  While he does provide plenty of evidence and citations, he is also not light on the sarcasm - he's not shy about calling ideas stupid and harmful if that's what he thinks.  Sadly, this last point somewhat undercuts his claim to impartiality.  The "opinion" sections are helpfully marked with a marginal icon and they're just all over the place.  And while I don't think that Meyer has any anti-agile ax to grind, I was definitely left with the impression that the preponderance of his commentary was critical of agile.

Now, to be fair, criticizing agile is not a bad thing - every movement needs critics to keep it honest.  If the agile advocates you find on the web are any indication, much of the material out there is very "rah, rah agile" and this book is a bit of a reality-check.  While Meyer does give the agile movement credit for a number of good and even brilliant ideas, advocating for the greatness of agile is not the point.  The important thing is to critically examine it and not just take the press releases at face value.

One of the nice features of this book's structure is that it has book-ended assessments.  That is, Meyer ends the first chapter with an initial assessment of agile and then finishes the book with his final assessment of the good, hype, and ugly.  Though only a couple of pages, I found the initial assessment actually quite good as far as putting things in perspective.  He begins with this quote (apocryphally attributed to Samuel Johnson):

Your work, Sir, is both new and good, but what is new is not good and what is good is not new.

To me, this sets the stage, highlighting that, regardless of the hype, not all of the "innovations" in agile are actually new.  In fact, some have been around in different forms for years or even decades.  Of course, not all the good ideas are old and not all the new ideas are bad, but the point is that agile isn't quite as ground-breaking as some of the hype would have you believe. 

I won't get into the details of Meyer's analysis, but there are a few interesting items I'd like to point out.   First is his point that agile proponents (and many others in the industry) tend to work on the assumption that there are only two development models: agile and waterfall.  They use "waterfall" as a synonym for "anything that's not agile," which is both inaccurate and unfair (page 31).  Innaccurate because  "waterfall" is a specific lifecycle model proposed by Royce in the 1970's.  Unfair because there are many so-called "predictive" lifecycle models which are not the same as waterfall.  For example, the idea of iterative development has been around for a long time, except under other names like "spiral model".

Related to this, Meyer makes the interesting point that not all of the predictive processes out there actually preclude agile.  His big example of this is CMMI (page 44), which many (most?) of us think of as a super-heavy process that's only used by government defense contractors, and only because the government requires it.  However, he argues, if you really look at what CMMI is, there's no inherent contradiction with agile.  Of course, the marriage of the two is far from a no-brainer, but it is possible, as evidenced by a report on a Scrum team that was certified at CMMI level 5.

This is just part of what seems to be Meyer's biggest problem with agile methods - the deprecation of "big, up-front" tasks, which seems to be generalized to all up-front tasks.  He seems this as emblematic of a tendency in the agile movement to take a good idea and take it to the extreme.  It's invariably true that you can't get all the requirements right the first time, that the initial archtecture won't be perfect, that the initial plan won't work out perfectly, etc.  Nobody's perfect and we can't know everything - that's just life.  But does that really mean that we should just not plan out any of that out ahead of time at all?  Isn't that just as good of an argument for taking some more time to figure out a better plan up front?

My own experience the last few years has led me increasingly to sympathize with Meyer's views on this.  Like him, there are a lot of agile practices I think are great and helpful.  Short, time-boxed iterations with frequent deliveries are a great way to work and collect feedback; having a good product owner is priceless; and I don't think anybody really objects to heavy use of unit test suites and continuous integration anymore.  Let's keep those around.

But the more I think about and work with various "agile" processes, the clearer it becomes that there's a reason so many people seem to say that their organization "does Scrum," but not by the book - they have this and that modification, sometimes to the point that it no longer sounds like Scrum.  Some people interpret that as evidence that agile is nothing but hype.  After all, if nobody implements that actual process, then in what sense is it successful? 

Of course, that's not entirely fair because every team and organization is different so no process is going to be a perfect fit for everyone.  But on the other hand, is it entirely unfair either?  If hardly anyone seems to do things "by the book," could that be because the book is wrong?  Without more of the type of researched analysis that Meyer offers, we really have no way to know.

If you're interested in development processes, then Agile! The Good, the Hype, and the Ugly is definitely worth checking out.  I have to say that it really changed the way I think about agile processes.  For me, it really helped to put things in a wider perspective than the "good/new agile vs. bad/old waterfall" story that seems to dominate discussions.  And if nothing else, it's at least good to see some questioning and critical analysis of the agile mantra.

(Note: for a shorter read, Jim Bird has a very interesting take on agile in a similar vein to Meyer.)

I've decided it's time to do a little professional development.  In other words, stop putzing around with whatever new technology is "cool" these days (grumble, grumble kids with their Snapchats, and their Node.js, and their Dan Fogelberg) and get back to fundamentals.  That means design and architecture, development process, project management, quality control, documentation, and all those other things that are important, but not even remotely "hip".

To that end, I'll be doing some reading.  The first book on my list has been on my bookshelf for about 13 years - The Mythical Man-Month, by Fred Brooks.  I bought and started reading the 20th anniversary edition over a decade ago, but never got around to finishing it. 

In retrospect, I think I was just too inexperienced at the time really get the significance of the book.  After all, it might be a classic, but its's an old book (written in 1975) about an old project (much of it relates to developing OS/360).  How relevant could it be?  Especially once you get past the punch line of why the man-month is mythical - which is revealed in chapter two.

Now, after almost 14 years in tech, it's easy to see just how brilliant a book it is.  While there is some discussion of obselete methods and technologies, that's beside the point.  The Mythical Man-Month is still relevant because it isn't really about specific development techniques or technologies.  It's about the complications of managing and communicating with lots of people on a large project.  And while we've come a long way as an industry in the last 40 years, the "human nature" part of the equation hasn't really changed appreciably.

One of the nice things about this book is that Brooks clearly gets what it means to be a developer.  He starts the book with an essay on the joys and woes of the craft of programming, all of which are as relevant today as they were 40 years ago.  There are a number of other such insights sprinkled throughout the book.  My personal favorite is his statement that all programmers are optimists.  When you think about the process of estimation and how that usually turns out, this is the sort of insight that seems so blindingly obvious that you're suprised you didn't think of it yourself.

The third chapter, "The Surgical Team," was particularly interesting to me.  The proposal is essentially to treat building software less like building a bridge and more like performing surgery.  So, in other words, you'd have one senior developer act as the "surgeon" and he and a core junior assistants perform all of the deliverable work.  The rest of the team supports him, doing the project management work, building supporting tools, serving as expert consultants, etc.  Since one top-notch programmer is supposedly ten times as productive as a mediocre programmer, having one of them do the work and nine other people support them gives you the same total productivity while reducing communication problems and maintaining design consistency.

One of Brooks' themes throughout the book is that the way to manage complexity is to maintain consistency of architectural vision.  That is, the overall system architecture should reflect as few viewpoints as possible, rather than being a mish-mash of the viewpoints of everyone who worked on it.  This plays into another major issue Brooks discusses: communication cost.  This is part of the reason the man-month is mythical - because not only does adding new people to a project add ramp-up time, it also increases the communication cost because you now have more people to keep in the loop.

I think one of the best things about the 20th anniversary edition is the added chapters.  For starters, they include Brooks' classic paper No Silver Bullet - Essence and Accident in Software Engineering, which is a good read.  It also includes a chapter of analysis and reflection, in which Brooks discusses not only the legacy of the book, but also what he got right and wrong.  The things he got wrong are particularly interesting.  They include the classic "build one to throw away" quote, which Brooks says is wrong "not because it is too radical, but because it is too simplistic," being rooted in the waterfall model that was popular in the 1970's, as well as his notion of communicating the full project workbook to everyone.

Overall, The Mythical Man-Month is a very engaging and surprisingly easy read, especially given the volume of references.  While it contains some details that now seem like quaint digressions into the history of computing, the majority of the material is still relevant.  It definitely contains useful insights for anyone who is interested in the dynamics of running a large project.  I'm very glad I came back to it.