I’ve been extra active reading blog entries lately and have come upon a few that have really got me kind of wired.
Software Development Dogmata – Good Practices Gone Bad
The first one is this article by Daniel Pietraru (who I do not know) over on little tutorials “Software development dogmata – good practices gone bad“. There are few major issues I have with this slight skewing of facts. Overall, excellent article, but there are some issues.
First is the “Agile != Flexible”. Read the manifesto, there is no such thing as Agile that isn’t flexible. The birth of agile that is mentioned is rather skewed too. If you truly want to learn about Agile, and you have a motivation to have good, happy, satisfied employees that are highly productive, look up the motivations behind Agile. Otherwise, don’t.
Daniel then goes on to negate the benefits of a short development cycle. Iteration based development has proven so effective almost every major process out there these days takes some form of this. As for the statement he makes “you cannot demo a car engine until it is fully built” is patently wrong. You CAN demo a car engine and that is the entire point behind computer models used solely to design engines, and cars in general, in a very LEAN or AGILE manner. So you can deny it, but I believe these methodologies, the focus on individuals, individual motivation, individual enablement, and other such characteristics of lean, agile, and others is exactly why Toyota has stomped the competition is is basically the world leader in automotive manufacturing and quality.
One really can’t deny Toyota’s success, and it is the prime cut of what agile is.
Pair programming, he has a slightly decent point on this topic. I too find myself torn about the usefulness of pair programming. It does, however have positive effects, but I don’t buy into the eXtreme Agile approach to the whole pairing with one keyboard and one mouse. Working together, communicating, and effectively integrating code into the main continuous integration serves just fine. But, I can’t really knock it either as I haven’t truly tried hard core pair programming.
He goes on to slander design patterns, TDD, UML, and a few other things that most developers are fully aware is very helpful in software development. Not sure why he hates so much of successful software. I ponder, what does he like about successful software?
In Daniel’s defense, he does have some valid topics, just the article is angry and seems to be centered incorrectly and lash out in ways that don’t do the points he makes justice. He does point to a very effective proven use of Agile methodologies, on a massive scale, for a company that turns a little it of profit now. Google – so read the WHOLE ARTICLE of Stevey’s (this guy works for Google and I’ve read his material several times) and don’t be so frustrated with Agile, there ARE good and bad versions. But I digress, on to the next.
Naming Conventions: Are They Really That Important?
I stumbled on this entry, I don’t know when, but somehow it reflected several conversations I’ve had recently. I like naming conventions, when enforced by ReSharper, Intellisense, or something of that sort. But to remember all, and then have new developers go about learning them all in today’s development environment is…
…well…
…an utter waste of time. Naming conventions are in no way important like they used to be.
Source Control is not a feature you can postpone to vNext
I just thought as I have many times, Microsoft doesn’t seem to get source control. Ayende @ Rahien (the awesome software simian) goes on a slight rant about the absurdity of their solutions so far.
Why are the Microsoft Office file formats so complicated? (And some workarounds)
It also seems that with my new effort to build awesome Office interfaces, tools, and solid back end architecture for these systems I’ve found the insanity of Microsoft’s Office file formats. I never realized, but Joel Spolsky, who I’ve read a lot of lately, worked on the Excel team at one point. He points out that there a more than a few pages (349 in one PDF) of documentation solely about the file formats of Office.
A Field Guide to Developers
Joel also did a great write up in the year 2006 about how to get a keep top developers happy and productive. Things like private offices, cool toys, a good physical work space, and one of the most important topics being the social existence of programmers. It points out the importance of having great colleagues, independence and autonomy, how they’re treated, and that there are no politics of the feeling type. As he states in the entry, “And this is the kind of environment you have to create to attract programmers. When a programmer complains about “politics,” they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.“. This, no politics philosophy, is absolutely 100% true!
Of only it was more common!
Top Five (Wrong) Reasons you Don’t Have Testers
…and an article on why a company, that intends to build good and reliable software should always have software testers. Again, by Joel Spolsky.
I also dug up another very interesting experiment that the company 37signals undertook. 4 day work weeks.
Workplace Experiments
Amazingly, they got the same out of a 4 day work week as a 5 day work week. Oddly enough people work much more diligently and effectively when they’re able to get a solid weekend of separation from work. This obviously wouldn’t work with every occupation, like for instance McDonalds would probably get minimal amount of use out of 4 day work weeks, but software developers are not McDonalds employees.
Another great article in a similar vein is Increasing sustainable pace. One of the comments is a classic combination of my railroading interests and software development, “Working more hours may not be the best solution. In the long run, working smarter always wins over working for longer periods. John Henry was the best rail spike driver in his day, and he died proving it. Power tools today let anyone work faster than John ever did.“. I firmly believe that smart workers will produce far more than a bunch of overworked code monkeys. In my experience this has a
lso been proven time and time again. This blog entry led me to a few searches, which then led me to some other articles.
That has been my reading for the day. It’s been a ton but I just got on a blog reading kick and figured I’d write up what I’ve read as of late.
