Jeff Atwood of Coding Horror writes an interesting article worth mentioning and reading by any programmers out there. He points out that there's only two types of programmers.
Jeff's article is based on Ben Collins-Sussman's article written about a week earlier. Ben writes:
The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational.
Jeff points out (not in so many words) that a lot of programming bloggers happen to be "alpha" programmers (or would like to be considered as much). These bloggers often forget about the 80% of the industry and take on an elitist approach to programming. I've seen this happen many times in blogger's attitude and content. Hopefully Jeff's call to programmers might have some impact.
I've always wanted to be in the 20%, but I know that I'm sitting over in the 80% boat. I'd like to think that I might know enough to be on the edge there straddling between the two groups, but I just don't use enough of the trending techniques, patterns, technologies, etc. to stay up to date on everything. Nor do I want to spend my weekends reading new software engineering, design patterns, etc.
If you're in the 20%, just don't forget about the majority of programmers out there. Most of us are still reading your blogs and experimenting with new technology, but some of us just don't have the time to keep up with everything going on or the flexibility to try as many different things at work as we'd like.
Jeff sums this up with a call to alpha programmers/bloggers stating:
If you really want to change the software development status quo, if you want to make a difference this year, you have to help us reach outside our insular little group of alpha programmers and effect change in the other 80% of the world.
This morning's Dilbert cartoon had me rolling. The pointy-hair boss commands Dilbert's team to start using Agile programming. In the boss's description, he states that Agile programming means "no more planning and no more documentation." The boss goes on saying that the programmers can "start writing code and complaining."
Jason Gibb writes an interesting piece about the decline of solo software developers (referred to as a superhero or cowboy) [via Arjan's World]. He claims that there are too many skills, technologies, and methodologies for one person to adequately handle.
Speaking as a superhero (err... maybe I'm just a lesser known mutant hero), I don't completely agree.
Now, in the face of modern software development methodologies, the concept of solo developers seems antiquated, almost laughable.
-- Jason Gibb, Software Teams vs. Superheroes
Although I'd love to be on a team due to numerous benefits such as learning from others and delegation of duties, unfortunately I've been a solo developer for most of my programming years. There has been the occasional co-programmer or DBA, but for the most part I've pretty much been soloing the development part of the projects and doing just fine.
It hasn't been easy or fun, but I've picked up enough skills to manage. To be honest, I've always felt a bit inferior to others who had the time and resources to specialize in a single field or at least a few less categories of the development processes. And being a jack-of-all-trades (master-of-none) has its downfalls with learning new technologies. However, there are also downfalls to becoming too specialized.
For today’s modern software, it takes a well-coordinated team of highly skilled, highly specialized engineers, designers, architects, database administrators, build managers, and Web professionals to create the next cool thing.
-- Jason Gibb, Software Teams vs. Superheroes
Jason lists several skills that a team must know and says that a single person just can't handle all of it. But, I'm not buying that...
I've used (or could claim to know) about 90% of the basic skills and almost all of the Web development skills. I would never claim to know everything about a particular item (and I'd question anyone's sanity who would such), but knowing enough to understand and implement (with using maybe some reference material - you can't memorize everything) usually works well enough to make good (or even great) software.
I also think it depends on the scope of the project. Solo developers aren't building the next version of Microsoft Windows or Mozilla FireFox. Larger projects require bigger teams with more specialized personnel. However, that doesn't mean the solo developer will die out.
I'd even argue that the vast majority of programming projects are not large scale projects, but consist of less than three or four people in the development team. And I'd even wager that most of them are generalists that overlap in a few common areas with maybe only one or two specializations.
In fact, I think the number of solo developers will stay around same level as now over the next few years. My thoughts are based on the trend of technologies becoming easier and requiring less skill to use - even though there's more technologies arriving each month/year.
Do you remember when you needed to remember the database specific SQL statements? Now that nearly every database vendor has an adequate development environment, learning the exact differences between the DML/DDL SQL syntax has become marginalized. Sure, you still need a solid understanding of database design and familiarity with the database specific tuning - you could even have a real DBA review the design and do some tuning - but for the most part it could be done by a single person.
As more projects move towards ORM and away from SQL, there's one less thing for the developer to learn. Sure, the developer would need to learn an ORM software, but seriously... just download SubSonic and you'll be up and running in a few hours (or less).
As far as web development goes, anyone that's being doing web development for a while should have an understand of almost all of those categories. However, since very few development projects are external, certain categories such as SEO and SEM doesn't really apply.
I think that generalists are here to stay. Why would a company who can only afford a few programmers only want their staff to know a handful of skills? And as a developer why would you want to limit your growth by only knowing a handful of skills?
At the current rate of change in the industry, the technology or standard that you specialize in could be dead in five years or less. Or maybe someone just out of college arrives and knows enough of the technology to impress your organization and they are willing to work at half or one-third your salary.
Alex Iskold writes about the Future of Software Development at Read/Write Web. There he makes a few nice points comparing the waterfall model to today's more trendy and talked about agile processes. He doesn't get into the various other software development life cycle models (SDLC) such as Spiral, Incremental, XP, etc.
In the real world, software projects have ill-defined and constantly evolving requirements, making it impossible to think everything through at once. Instead, the best software today is created and evolved using agile methods. These techniques allow engineers to continuously re-align software with business and customer needs.
Alex talks about the failures of the waterfall model, which most everyone should have learned in college or during any reading of a good software engineering book.
The only part of the article that I don't seem to grasp is the intentional exclusion of mentioning the .NET framework. Even if the author doesn't like the framework, surely it is worth a mention in his list of "modern programming languages." In his list, he only includes Java, PHP, Python, and Ruby.
A few commenters pointed out the lack of including the .Net Framework as a modern language or reusable library. David Murphy of BuzzSort wrote "On... The Future of Development" and reminded us about Workflow and LINQ (two of the newer .NET technologies).
..whilst it was an interesting read I believe the picture it left was incomplete and inaccurate.
I believe that all of the agile buzz over the last several years is just a fad and eventually the good items from the agile processes will just be commonplace in the development environment (we'll probably have a new name for it by then). Just look how some of the agile processes are now being incorporated for the masses (Microsoft Solutions Framework (MSF) for Agile Software Development, Microsoft eScrum).
I also believe that there's not one technique, model, or set of methodologies that can work for every project or team. And that it is the job of software engineers along with project managers to help focus the energies and talents of the developers and designers to make the best possible product.
Having fewer developers and a good strategy should result in better products. This is the same conclusion that Bob Warfield came to in his article titled "To Build Better Software, You Need Fewer People (But Why?)".
A few choice quotes from the R/W Web comments:
Waterfall said "I can't see anything you've described not being possible by following the waterfall method. Somehow people have turned the phrase agile development into a mythical beast capable of achieving miracles."
Paul W Horner said "Software developers have always had huge problems when working in large teams. That hasn't changed at all. In many ways Agile is just dodging the real issues."
Jimbo said "There's much more to software than web 2.0, search engines and social networking sites."