A widely demanded feature delivered with Visual Studio 2005 is "Edit and Continue"; which is the ability to alter running debug code to incorporate code-changes on the fly: You're debugging and realize that you initialized a variable to the wrong value, or your loop control has a off-by-one error. You pause the run, quickly hash out the changes, it builds it into the running image, and you continue debugging from where you were.
Great feature that can be a tremendous time saver, avoiding having to stop the session, make the changes, rebuild everything, and then begin the developer test session anew.
Is it, coupled with similar tool advances over the years, making programmers generally sloppier, though?
Observing the habits of many peer developers in the field, I would say that it and similar advances absolutely have made us more careless in general: The less expensive errors become, the fewer checks and mental effort we'll expend ensuring that they don't get into the code in the first place. We're continually pushing the onus of catching errors one level higher.
To contrast with a slightly earlier time, there was a time, way back when (circa 1990), when I was plugging away with DJGPP (GCC for MSDOS), editing the source files in a simple DOS text editor, exiting out, building (very time consuming, with few benefits like precompilation), and then running. It was such an onerous, expensive process that I put a significant amount of care and concern into every single line of code. I would follow-up careful coding by going back and auditing every single function and interaction to ensure that it was syntactically accurate, but more importantly that it was logically accurate.
The cost of an error making it to the next level was high enough that I was very motivated to avoid them in the first place.
After such a personal code audit, I was very confident in the code, and it was very rare that an error made it any further: The cost of an error making it to the next level was high enough that I was very motivated to avoid them in the first place. The original level of quality was high enough that few additional checks were actually needed - it simply worked correctly for all scenarios.
Of course I had it incredibly easy in contrast to those who programmed before (I already had the benefit of a significantly easier development process). I'm sure the folks who programmed punch cards redoubled and tripled the effort again, achieving amazingly high at-origin quality levels in their code: You can't just spit something out when you're printing and sorting punch cards, and then feeding it into the mainframe during your tight allotted time window. Nor did programming assembly in the 8-bit days leave much room for errors.
Contrast this with the habits of many developers today (myself included at times): Spit out a bunch of code, occasionally hitting compile/syntax check to automatically detect gross syntax errors. Build and run, and if it blows up then follow the exception back to the error and correct it. Drop into breakpoints and watch what values are to ensure they're what you wanted (a modern variation of printf debugging), and if they aren't then use edit and continue to quickly hash in some changes. Keep debugging. Run the TDD sets to ensure that the superficial, incomplete collection of tests "guarantee" that the code is "perfect".
Toss the result over the wall to the QA department. They're likely running a macro script that tests a small sub-section of the code, so there are few guarantees there either. In the corporate space, they'll throw it over the wall to the UA testers who again will likely only catch the most obvious of errors.
Deal with the inevitable problem when failures occur in the field, pointing out their inevitability given the numerous layers of quality control you have in place.
Of course some developers will strongly object to even the possibility of such a scenario: Their code is flawless at inception, crafted with the utmost of care and concern, and they need never evaluate their habits or tool usage because they couldn't possibly come closer to perfection. That level of ridiculous denial is destructive on any team or project, and I can offer no advice on how to solve or manage it (though it's the foolishness of the inexperienced, so generally developers grow out of such bravado with time). Instead I choose to deal in the real world, with real developers on real projects in real organizations.
For all of the process (including layers of QA, UA, regression testing, and so on), many errors aren't caught at many shops until the code reaches the field, which is why it's critical that they don't enter into the code in the first place.
the addition of layers can paradoxically increase the probability that errors will be introduced in the first place
Indeed, sometimes the addition of extra layers can paradoxically increase the probability that errors will be introduced in the first place: At one very large organization where I observed development firsthand, developers would hand their obviously flawed code (it was clear that there wasn't even a superficial quality check) over the wall, doing so knowing both that there was a QA department that should catch these things (and if they didn't then it's their fault if it makes it further, exonerating the developers even more), and if that department does find a fault it came as a largely ignored problem report that held few ramifications or negative implications.
Change precisely what was documented as defective, rebuild and resubmit.
Eventually the QA department would pass on the code to the UA department, which was a set of user testers that simply relied upon the comforting idea that the developers and QA surely would have found any possible faults. UA could be relied upon largely to restate long-known system limitations instead of verifying the changes.
All of these layers relieved developers, and each of the other layers, of the real responsibility of defective code. Advanced tools facilitated sloppy coding in the first place, and layer upon layers of ineffective checks ensured that there was little actual responsibility for faults that made it to the field. In the corporate space where developers generally don't have a passion for the software they're creating, the result was often of questionable quality.
It would be an interesting experiment to have two concurrent mid-sized projects, each completing the same task, with one development team having a modern complement of development tools, and the other with no ability to automatically syntax check, run automated tests, or debug in any way outside of a small number of scheduled debug builds and test sessions. It would be interesting to evaluate both the overall timeline (did the tools save much time?), and the quality levels of the resulting product.
I believe that the results would be very surprizing to many software developers. In real world projects (e.g. not pre-project timelines, but actual post-mortem results), approximately one half of development is dedicated to finding, and fixing, software faults. Making the per-item cost of faults cheaper may reduce the per-fault cost, but it also might increase the frequency of faults to the point of being a net loss.
A comment that I frequently hear relates to the efficiency of development - That modern tools make us so much more efficient. Under the right conditions, and with proper usage, this is certainly the case. Edit and Continue, for example, could be a very useful feature once every blue moon. Yet by the outpouring of demand for that feature, one would think that developers were crippled by the inability to alter running code: The responsibility to craft quality code before hitting build was just too overwhelming. This is a sign that quality code craftsmanship is on the decline.
Tagged: [Software Development], [Programming], [Software-Development]
...is that they're often fact-deficient.
The rumor that's been making the rounds over the past 24-hours is speculation that Microsoft has bought, or is buying, Opera (the makers of the excellent Opera web browser). The source of this multi-hundred-million-dollar rumor, involving two publicly-traded companies, is one small, random, tech "ezine". Nonetheless it's been repeated on Slashdot, Digg, along with many other sites and blogs.
The indirect birthplace of the rumor - perhaps the source of the plot for someone's fiction - was John C. Dvorak's commentary yesterday that Microsoft should buy Opera, given that they're letting the IE browser rust on the Mac. Opera, Dvorak claimed, would provide Microsoft with a cross-platform solution.
The problem with Dvorak's hypothesis, among many other logic gaps, is that Microsoft doesn't want a cross-platform solution. Internet Explorer on the Mac wasn't abandoned because it was too difficult to maintain, and it certainly wasn't that Microsoft couldn't keep up. Instead, it was strategically abandoned because Microsoft couldn't rationalize spending the time and effort to create a browser for someone else's platform. It also brought Microsoft under additional scrutiny: It's one thing for the monopoly operating system vendor to use some of those profits to enable their own platform, but it's quite another to provide a free browser to edge out competitors on other platforms as well. Internet Explorer on the Mac undermined Microsoft's bundling proposition as well (the whole "it's a part of the operating system...that you can also run on other operating systems...").
Ultimately this rumor is so void of any logical foundation that it is an indictment of the group-think sites that it has gotten the attention that it has (though it got the originator website exactly what they wanted, which is a lot of attention). Once again I'm setting myself up for a hearty serving of egg-on-the-face, boldly proclaiming that it is very unlikely that this story is true, but that's exactly what I'm saying. At least the Google-buying-Opera nonsense of a month or so ago could be mentally rationalized to some degree, but Microsoft-buying-Opera is just over the top ridiculous.
On top of all of that, there are some legalities that are certainly going to start biting small internet papers and blogs that perpetrate this sort of rumor mongering: Making false statements about publicly traded companies in ways that can impact their valuations might seem like a harmless, fun way of boosting the hits, but there are legal restrictions on that sort of fiction. I'm not saying with certainty that this particular story is untrue, but it seems highly likely to be the case.
UPDATE: While scanning the discussion boards, I've noticed that a common technique to keep the hype alive is to focus on the mobile market as Opera's killer valuation: Opera has a micro-browser that runs on cellphones, therefore that legitimizes the purported buyout (as only the few true believers would think that Microsoft replacing IE7 with Opera is even remotely possible).
There are several problems with this.
The mobile angle does nothing to rationalize the scenario.
[The static location of this piece can be found at this address]
Rediculous - Results 1 - 10 of about 3,800,000 for rediculous.
It is ridiculous that such an obvious misspelling has become so prolific (correctness by repeated assertion), yet it's a great example of how contagious an incorrect spelling can be: Given that language is largely learned by example, it is inevitable that an endless exposure to malformed spelling will eventually infect the language of others, gathering a widening net of victims.
This is more of a problem now more than ever, given that many of us have supplanted - or entirely replaced - the professional writing in our lives (newspapers, books, professional papers) with the amateur writing of bloggers and forum posters: The "good" influences - carefully authored, carefully edited professional writing - have given way to carelessly hashed-out entries by time-pressured bloggers and marginally-literate forum posters, in a domain where the accepted rules of netiquette strongly discourage pointing out spelling or grammar mistakes.
Those who point out errors in grammar or spelling are quickly marginalized as "Grammar Nazis". Ignorance rules the day, and the social pressure encouraging good spelling and grammar has dramatically declined.
English is a very difficult language, with a tremendous array of conflicting influences, and a byzantine array of specialized rules and conditions.
It is, for instance, very difficult to conform to all norms of grammar given that many of them are subjective and conflicting (and many self-appointed gurus have themselves made embarrassing errors). I have absolutely no doubt that this entry, for example, has over a dozen real or subjective grammar problems: From the incorrect placement of a comma, to the overzealous use of a compound adjective, to the use of a colon where a dash would suffice.
I certainly make no claim of perfection. Where I find that I've made an error (and I heartily welcome emails to this effect), I try to correct them as quickly as possible.
Nonetheless, spelling is standardized (with minor regional variations), so unless one is intentionally trying to extend or adapt the language, some effort should be exerted to check the standards references to ensure that one's usage is conformant, just as one would ensure that their CSS or HTML was compliant with the pertinent standards.
The impact of the continued exposure to incorrect spelling and grammar can be extraordinary to observe. I've seen people corrected dozens of times, yet rediculous is so ingrained in their mind that they just can't break the habit. Soon enough other participants are perpetuating the misspelling, with the forum slowly diverging from correct English into some bizarre forum-localized lingo-ignoramus.
It might seem harmless, but this incorrect spelling starts infecting their professional writings (emails, instant messages, documents, signs, business cards - a domain where the laissez-faire attitude of the online world isn't acceptable), making them look ignorant and careless. That's if the fear of the same hasn't discouraged written discourse altogether (which is sadly very common. I've encountered plenty of professional acquaintances who avoid the written word like the plague).
It can even reduce the comprehension efficiency of written materials, as the reader's brain tries to rationalize the correct spelling on the paper with what they have stored in their memory cells.
It reduces general literacy.
If a reader's first exposure to analagous (analogous) or ancilliary (ancillary) are in a hastily written blog entry or forum post, naturally they're going to adopt the incorrect variant, perpetuating it to other entries and posts. Like a virus the misspelling infects new victims.
Of course it should be noted that language is indeed a "living" thing, and it does evolve and change over time - the English we speak today differs greatly from the English of yore - but the sort of ignorance that I'm describing has nothing to do with extending or adapting the language. Instead it's simple contagious laziness.
Good form or not, I am regularly going back and rewording old entries for improved clarity and readability, and occasionally even to correct spelling mistakes that made it under the radar (I have some eagle-eyed readers that very helpfully point out some of these errors. Rather than being irritated by the "grammar nazis", I am very appreciative to have the extra sets of eyeballs).
I do this primarily to ease consumption by readers: While the initial entry might have been rushed when too little time was available - but I thought the information or perspective were useful for someone - the entries live on and see far more traffic over time than at the outset. A correction here and there, and the refinement and rewording of a paragraph or two to make it more clear and concise, takes me a few moments, yet it saves dozens or hundreds of readers time in the future (and improves their comprehension of the content).
I consider the effort very worthwhile.
Furthermore, I try to run all entries through an up to date spell-checker before the initial publishing. To make the process more palatable, I have trained the spell-checker with all of my domain-specific terminology (the false-negative rate of spell-checkers is one of the primary reasons most people avoid them).
I don't want to appear ignorant by misspelling a common word, and I don't want to save myself a little time at the cost of every reader's time. I also don't want to pollute the vocabulary of readers with believable misspellings.
Just as one eagerly sticks a W3C validation banner on their page declaring their compliance with some level of specification, it would be intriguing to advocate a "spelling and grammar" standard mark. One that simply declares that the author actually cares, and does exert some effort to meet some minimal level of correctness in spelling and grammar. It would be a public sign indicating that they are open and thankful for comments and corrections regarding the same.
Furthermore, it would be advantageous if the major search engines - including blog aggregators and search engines - allowed one to refine results by grammar and spelling, optionally scoring academically correct content higher in the results. While sloppy spelling is no guarantee that the content isn't of value, there is a noteworthy correlation between the care and concern put into the spelling and grammar of an entry and the value of the actual content contained within: If someone couldn't bother spell-checking their entry, the factual content of their entry naturally has to come into question as well.
In the forum and blogging world, it would be beneficial if more tools supported convenient and efficient automatic spell-checking (the fact that no major browser has incorporated native TEXTAREA spell-checking thus far is a travesty. Any of them could have a killer feature if they simply added Word-like squiggly underlining of suspect words, with easy alternative corrections). As it is, many tools have nothing at all, and the few that do often host a ridiculously unintuitive, hacked-in partial solution.
Let's clean up English on the internet.
[TRAFFIC NOTE: This story, one of the few general interest posts I've made on here, has appeared on reddit, sending quite a few users this way. For those who've actually read this far, if you found this entry interesting I would appreciate if you could give an arrow up to it on reddit. Alternately if you think this is a dud, please give it an arrow down. Thanks!]
Rearranged the shelves over the holidays, and re-read a few sections of Fred Brooks' venerable book The Mythical Man-Month.
It's an interesting read, though it is largely obvious: Adding more people on a project naturally means more administrative, communications, and coordination overhead. If, at a particular stage in the project's progression, you have more people than you have clean project partitions, they could actually hinder rather than help.
Many developers can personally identify with this indisputable observation, recalling situations where a manager with excess human resources dumped workers onto their project, against their wishes, while it was in an unpartitionable design stage. A co-op student assigned to me in just such a situation, many years back, started informally tagging their assigned tasks "MWPs" : Make Work Projects (they were quite capable, and recognized and disliked trivial tasks). Given that I was in a critical, non-partitionable task, and all following tasks depended upon it, the best I could do with their help was to get them to do competitive research.
Such is the nature of some projects during some stages. To use the classic analogy, nine women can't produce one baby in one month. Of course it's a fairly bad analogy given that those nine women can of course produce nine babies in nine months, effectively producing a "baby a month" if you wait the minimum period, but nonetheless it is the common phrase.
The mythical man-month title refers to the fact that many project managers take a project's estimated work (e.g. 100 man-months), and then request or assign a set number of people (e.g. 10 men), dividing the effort by the workforce and considering that the delivery date (in this case 100/10, or 10 months to completion from the start). Of course that is incredibly naïve, and is a recipe for disaster from the outset, and when the project starts slipping more people get added, slowing the project even more.
Thankfully, most shops use proper project timelines now, with critical paths, dependencies, and task assignments.
A couple of Mythical Man-Month quotes that I found enjoyable:
An ancient adage warns, "Never go to sea with two chronometers; take one or three."
...
An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint.
As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get sorted away to be used "next time." Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.
The second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.
If you don't own this book, you should at least get it to stock your bookshelf (it is a required pretend-to-have-read shelf stocker). If you already understand and believe the core message of it, it's debateable if it's really worth spending the time actually reading, though: Quite a lot of it is highly specific, unique observations about the creation of OS/360, and some of it are practices that are now considered questionable. For instance, few advocate the surgical team that the book promotes (with the book example humorously including a language lawyer and two secretaries).
Getting back into the flow after the holiday break.
In addition to branded software, yafla also provides consulting and custom software development (in the Greater Toronto Area), which has kept me extremely busy over the past while. That's an area of the business that I haven't really written about (primarily because I keep client project and platform details strictly confidential), however I have a case study where the client is interested in getting their name out there, and the need - and from it the solution - are really interesting and noteworthy, so I might start working it in.
As an aside - both the survey component and yaflaColor are currently broken (as of this writing). Both have been updated to .NET 2.0, and for some reason my third-party host has an issue where helper assemblies are being locked by an outside process, possibly due to synchronization issues with the NAS. This should be resolved shortly. I've let them sit broken for the day simply because they're non-critical and it lets the 3rd party solve the problems on their end.
[The static location of this piece can be found at this address]
Work habits and conditions vary dramatically between software development groups.
At one extreme of the spectrum are productive, tuned development
teams delivering solutions on schedule and on budget, staffed
with passionate experts happily building their skills and
careers while providing valuable cutting-edge solutions. At
the other extreme lie dysfunctional, under-utilized teams. The
latter group endlessly catapults magnitudes past estimates of
time and money, with a 
revolving door roster of
contemptuously-treated employees.
Most shops fall somewhere in-between -- imperfect, but continually working towards better, more efficient practices and process, all while trying to provide a rewarding, fulfilling, and career-building experience for team members.
This entry is targeted at that continually-optimizing audience, and is written largely for development group managers and team/group leaders, though it's still informative for the general development community (lateral and upward management is critically important, and is the force that drives most process change).
These observations are gleaned from my experience with teams of varying sizes and types, acting in a variety of roles including management, team lead, developer, process consultant, mentor, mentee, and technology consultant. I have directly participated in, or observed, the development process in small, tightly-knit engineering groups stocked with professional electrical engineers, to mega corporations with walking-dead teams awaiting the next executive shuffle to mete out some doom on their orphaned projects.
I've learned from the successes, but I learned even more from the failures.
I've focused on best-practices that are optimal in virtually any team, and which are frequently evident problems, while avoiding those that are more likely to vary significantly between teams and organizations. Work environment, for example, is very subjective and context specific: Some developers and teams work optimally in private, quiet offices with comfy chairs and scheduled communications, while others thrive in hectic, noisy open offices, interfacing directly with the "customer" throughout the day, eagerly setting up development kiosks on whatever can serve as a seat. Some organizations need armies of BAs and BSAs and QAs and UAs, with layers upon layers of heavy process and checks built atop a traditional waterfall development model, while other shops work best with a highly agile, frequent delivery model, completed by multi-role development resources. It isn't possible to declare universal best-practices within those domains.
I also appreciate that most real-world teams have budgets, and that feel-good lists of .COM-style excess aren't realistic or helpful in the current IT climate. Every developer doesn't need every tool available, or every electronic toy on the market, to do their job effectively. I haven't tried to pander to the development community, blowing smoke about how entitled and empowered they should be, beyond the level that is actually beneficial to their career and the role.
On to the list!
Select processes, practices, and standards based upon your particular type of organization, type of project, and workforce, and then customize them for your specific needs.
Of course this suggestion seems ridiculously obvious, yet this is an industry rife with groups foolishly mimicking the process of those who appear to be successful.
Whether it's the previously agile vertical-solution shop trying to act like they're a bank, overloaded with process and CMM levels far beyond necessity because that looks like what the "big boys" do, or the banking group trying to adopt XP practices and frequent deliveries because it's the hip new trend that all the blogs are talking about, when their product only requires bi-yearly deliveries under a heavy layer of checks and balances: What works for one type of organization doesn't necessarily work for another, and adopting those processes under the wrong environment will bring defeat rather than success.
Don't act like you're developing life-critical flight control software when you make a P2P app, just as you shouldn't do the opposite. Don't pretend that you're an ISV, or assume that much of what's right for a retail software vendor is transferrable, if you're actually an in-house IT development shop.
This sort of cargo-cult mentality exists at a lower level as well. During the .COM boom, success apparently came from stocking up on Aeron chairs -- Get the chairs, and you'll do well. After the collapse the idiocy continued, with the same chairs now being demonized: Now they could only bring doom, and had to be removed post haste. It's a chair people. In the grand scheme of things, it really isn't going to make that much of a difference, positive or negative.
The same could be said about foosball tables; catered lunches; big, corporate-style meetings; having big cozy offices for everyone, or tiny open plan offices for everyone. Someone seemingly did it to their success, so therefore it was perceived as an applicable practice for everyone.
Just because someone else benefited from it doesn't mean that it would benefit your organization. It could very well hurt your organization.
Source control is the foundation of good coding practices.
Not only does source control keep your code centralized (facilitating organized access for developers, along with easy backups and automated integrity assurances), with the proper use of branching and labels it can greatly increase the agility of your team: Having the comfort of making major changes in a code branch, while retaining the ability to revert to a labeled release or trunk, is liberating, reducing developer paranoia and ameliorating the risk of change.
Whether you're using Microsoft Visual Sourcesafe, Perforce, CVS, or one of the countless other available source control products, it is a critical component in your toolset. It's critical even if you're a single developer working alone in your one-man software development shop.
Source control is also invaluable for change management and auditing, historically tracking how much has changed, and where, over a given period of time, which is a benefit that often pays off handsomely years later. For example auditing the code history to determine when an errant algorithm was introduced to gauge how long it's been screwing up the calculations.
Adequately trained quality assurance teams can even use source control to determine what has changed between releases to tightly focus their testing efforts without relying on the often incomplete word of the developers.
The technique to use source control properly depends upon the tool that you're using, and the standards and needs of the group: Some groups use source control only to check-in production releases, while other groups check code in frequently, with every developer checking in multiple times per day, merging branches at convergence checkpoints. Ensure that you know the feature-set of your source control package inside and out, and that you're following a rational, best-benefit standard of use for your scenario.
If your usage is non-optimal because of limitations of your SCM tool, consider a product change. It really is that important.
Tip: Frequently perform project builds on a clean machine with limited network access by following development environment configuration instructions, and then getting and building from source control. During this process many teams discover hard coded paths, missing dependencies, and solution defects. It's better to detect it early than for development to grind to a halt the day before a big release when the corporate IT department decommissions that old server that supposedly wasn't in use for the past year.
Standards can be extraordinarily detailed, or as simple as noting which industry standards a team subscribes to (e.g. "All .NET coding will be done in conformance with the Microsoft .NET Design Guidelines"). It could even be the formalization of the lack of specific guidelines in a certain realm (e.g. "Put the braces wherever you'd like, and either tabs or spaces are fine"). Documented standards should cover all aspects of development, including development environment, tools, accepted languages, best-practices, check-in behaviour, naming guidelines, and so on.
Of course standards should be living documents, with occasional reassessments leading to the removal and addition of new points.
If, on the other hand, your standards are word-of-mouth, or "by example" (usually with many conflicting examples throughout the organization), you don't really have standards -- more likely it's acting as a demotivating, inefficient confusion for newer developers to the team, and a constant political skirmish between the veterans of the group: While good developers will happily adapt and conform to the idiosyncrasies and preferences of a group or project, it is frustrating and unproductive when they have to constantly go back and rename tables and rework classes because of unwritten "standards" that exist only in the minds of a few. When developers lose confidence in their code because of uncertainty over trivia such as spacing standards, something is seriously wrong, and people are focusing their care and concern on something that should be thoughtless.
As an added benefit, the process of documenting standards is often a time for rational debate, when "that's the way we've always done it" standards have to be legitimately rationalized and justified, or rightfully discarded. Many teams have improved their process, finally jettisoning unjustified legacy standards, during just such an exercise.
Having concise, documented standards (which can be the documented absence of standards in a particular realm) saves everyone from having doubts about whether they're conforming, eases new developers into the fold, and increases the percentage of good standards while removing the excess baggage. It also facilitates external assistance more smoothly.
Every project, and every team, should have a daily or bi-weekly status updates by every member to their team leader or manager, or better still to every other member of the team (including from the manager to the team). This is regardless of your development methodology.
This can be a scrum, or a simple daily email stating what work the person is planning for the day, and what they achieved during the past day/period. This practice not only keeps everyone focused on the task at hand, with better time accountability (just like everyone else, and possibly worse as a group, developers are procrastinators), but it also gives a transparency of development that let's the manager, leads, team members, and stakeholders see where impediments exist, providing them an opportunity to help, or to recognize and respond to schedule slip early on, before it becomes a crisis. This transparency is one of the fundamental goals of the CMM process, and the benefits can be largely gained just by frequent, scheduled, mandatory and accountable communications.
Optimally this information will also exist in an archived, centralized, widely accessible location, such as an audio recording of a scrum, or a centralized collection of update notes.
It is critically important not only that this information is conveyed, but that it's actually consumed and retained as well -- management and the rest of the team must pay it proper heed, and they shouldn't wallow over during the day to ask what was previously stated. That undermines the entire process when it turns into a wasted effort that no-one pays attention to.
Having lots of specifications, standards, code libraries, discussions, solutions, and examples strewn across the topology of the network is of little use to anyone, and can be detrimental. Outdated documents will continually reappear, and misinformation takes on an unstoppable life of its own.
Centralize and standardize, ensuring that everyone knows exactly where to find all pertinent information on a moment's notice. Everyone should know exactly where they can find, and thus where they can store, specific types of information.
As it is, many teams start off with the "dumping bin"-style repository when they begin a project, planning on sorting it out later, however soon enough there are GBs of files -- many of which have little or nothing to do with the product or project -- confusingly cluttering a massive mess of a directory structure. This puts a serious damper on productivity.
Documents can't be found. People have to constantly interrupt each other to ask where to find something or where to store something. Eventually an expensive initiative will have to be undertaken to separate the wheat from the chaff, at a time when most people have forgotten why all of the various unrelated information is there in the first place. Undoubtedly good data will be removed, and bad data will be retained.
Before you create the first project or product file, decide exactly how you're going to organize the information, planning for the long term. Who will have access to it, and what permissions will they have? How they will access it? What will be contained where?
Tip: Documents such as specifications yield the same benefits of source control.
The first step of any project shouldn't be to hit the IDE, or even to start high level design work. The first step should be to research and understand all competing or similar products, and any and all libraries and tools that could be leveraged to empower your solution.
As I write this, countless teams are spinning their wheels reinventing the Microsoft Application Blocks, or they're developing a data transformation service that could be integrated in Biztalk or SQL Server Integration Services less expensively (and much more flexibly). Perhaps they're developing a web portal that's just an incomplete, second-rate clone of SharePoint, Community Server or Zope.
There are even teams duplicating functionality already existing in the .NET Framework or standard template library because they never spent the time to look.
For virtually any need there are libraries and existing solutions that could either replace the need for the project altogether, or more likely could serve as a foundation of a more robust, more capable solution. If you're in the solution business, the desire to propose and implement the best solution should trump any desire to code for the heck of it.
Developers can't complete that sort of competitive research in an afternoon, or as a footnote, nor should you rely upon off-the-cuff commentary provided in meetings by individuals vaguely aware of the options.
While it varies by project and industry, such research usually requires a significant upfront investment of time before coding begins, allowing the stakeholders and development group to all feel entirely confident that the project is justified and will yield the best possible results. Document every finding and decision to save endlessly having to explain why one decided to develop what seems to be a clone of Biztalk.
One of the primary reasons why many shops continue to grossly under-estimate the time required for projects is that they have limited, or fictional, historical real-world time tracking to base future projects upon -- they might have half-a-dozen developers working full-time, but the best they can account for at the end of the week is that a couple of small app issues got worked on.
This is sadly very typical.
Where there is some form of time tracking system in place, often it is of little value: Developers, as a general observation, will try to find ways to under-report the amount of time they spent on a particular development problem or project, as it's a bit of a badge to claim to have "thrown together" complex solutions in a "couple of hours". Furthermore few shops properly partition times (e.g. by project stage and task), further blurring the value.
Implement a time tracking system, and coach your team to accurately and regularly post times (daily, if not more frequently. Any less frequent and accuracy suffers dramatically (as someone with the bad habit of filling out timesheets at the end of the month, anxiously looking at file timestamps to figure out what I worked on when, I say this from personal experience).
Ensure that there is enough granularity that the time reporting is usable. For instance that you can see that competitor research actually took two weeks, instead of the foolishly anticipated 2 hours.
Avoid tacitly encouraging false timesheet entries: Don't act concerned when real world values start appearing, and most tasks are much more time-intensive than originally thought. Adapt and accept that reality differs greatly from the mirage that most people imagine that they see.
You have your team of six hyper-intelligent and eager software developers, overloaded creating the next great scrum-tracking application. Based upon some user feedback, you realize that a small percentage of your users may want to interact with the system in a minimal way using J2ME equipped cell-phones, but your team is entirely staffed with .NET experts. Do you a) add a J2ME developer to the team, and just try to expand the J2ME product line, b) let one of your existing developers try their hand at J2ME, c) outsource that non-core component. Most shops would pick b without hesitation, incorrectly justifying it under the guise that it's "free" because it's covered by the payroll.
If you decide to try your hand at it in-house -- despite the considerable domain difference -- the results will almost certainly be a second-rate solution, delivered more slowly and more expensively than just outsourcing the need. This is worsened in that a resource originally dedicated to the core product has been diverted to a non-core need, and will come back to the core product with a need to spend time reacclimating.
This isn't to say that this is always a bad solution: Sometimes it entirely makes sense to build such skills in the core team (if this is a component that will need regular modification, or if it's an expanding customer base), not to mention that the work diversion can prove entertaining and rewarding for a developer.
Undertake non-core competencies -- be it building a one-off data bridge to a partner, putting up a corporate website, designing logos and icons, or countless other non-core needs -- with eyes wide open, realistically assessing the cost to do it in-house. Estimation of the "knowns" is already notoriously bad in software development, but the situation is far worse for non-core competencies, where developers are prone to extraordinary underestimations.
Realistically consider leveraging external solution providers (or even other teams within the organization) where it can keep your group focused -- with appropriate communications, teams will understand that it enhances their value and effectiveness, rather than presenting a risk to their employment. [Note: My organization provides outsourced consulting and development, so I do have a conflict of interests. However we always go in with the intention of empowering and furthering the existing team, and never to supplant them]
Getting the team working on nights and weekends means little if it saps their passion to produce, expensively inflates the bug count, and increases turnover. Yet sadly a lot of managers work under the delusion that effort and sacrifice are worthy substitutes for results. Indeed, many management techniques are built entirely around deriving maximal effort and demanding complete sacrifice, inventing artificial deadlines and manufactured crises to prod the troops.
The results are invariable destructive and counter-productive.
This is rooted in basic human psychology. Just look at a famous cough syrup with a heavy advertising presence: Surely it must work better because of the sacrifice required to ingest it? Contrast that with the presumption of self-destruction that most attribute to activities that people find enjoyable.
If it's fun or requires little sacrifice, then it can't be beneficial. If it is unpleasant, then it must be doing good. These foolish and unfounded notions have sold a lot of snake oils over the years, and they've supported a lot of human folly.
Savvy Machiavellian developers know how to exploit this management myopia, under-delivering until crunch time, and then putting in some superficial extra effort to get the project done, yielding kudos all around for going "above and beyond". Just by finally delivering long overdue results that they could have achieved in the normal workday. This is especially the case in shops with limited time reporting, and no regular status updates: Show up early in the morning (sending emails as validation), grunt and groan and gripe, shuffle around regularly, and then leave late (again sending emails to validate how committed one is), maybe VPNing in during the middle of the night to again demonstrate great sacrifice.
In some shops that alone is a substitute for any results at all.
On the flip-side, the "slacker" that comes in at 10am, leaves at 4pm, and takes extended lunches somehow keeps generating the bulk of the product design and code, but his apparent lack of effort and sacrifice will be dealt with at the next performance review.
Many heavy and onerous processes are undertaken, and then maintained, not because they've empirically proven themselves to be useful, but rather because the effort involved gives a mentally cheap illusion of achievement. From volumes of documents that no one ever references or validates, to arduous signature gathering exercises. Most of the time they're the mindless completion of a task with no real benefit to the project or the process, but it goes unquestioned as a part of the flow.
Discard all processes that are mechanically completed with little actual benefit. Tweak those that require more effort than necessary, maximizing the results while minimizing the effort.
Effort alone doesn't make your quality better, software better, or team smarter. Focus on results, and welcome and encourage results that come with minimal apparent effort or sacrifice.
Building a top-notch, effective software development team is a lot of hard work, coupled with a bit of luck, but hopefully some of these points have given a bit of food for thought that might encourage some development in the right direction. This list most certainly isn't comprehensive, and I've stayed away from domain-specific practices, but it is a start.
Tagged: [Software Development], [Programming], [Software-Development]
an overwhelming percentage of software developers imagine themselves to be far above the norm - they themselves conveniently fit that top 2% echelon, they believe
Several readers have emailed to ask how my "Optimal Software
Development Processes and Practices" entry -- which was
surprisingly well received -- compared to several better-known
software development guideline papers. For instance Joel Spolsky's
superlative "The
Joel Test: 12 Steps To Better Code".
"Read them all and then adopt what sounds right to you," I replied.
To expand upon my answer a bit, my entry is a listing of high-level management practices that apply to virtually any team involved in virtually any type of software project. If you have accountable software developers; you're focused on solving the right problem, using the right platform, tools, and technologies (given that they've done the research, and they're not tied up having camelCase/PascalCase wars, developing a redundant GFA Basic solution for the Atari ST); you have a history of accurate, detailed time information to draw upon for estimates and to really know the capacity of your team -- which usually indicates a grizzled, experienced management that is more attuned with reality than is the norm; you have full transparency of how the project is progressing and what is getting done; then you have a much better probability of success.
Yet these basics -- these core fundamentals -- are sadly missing from many software development teams.
It is, however, fairly typical of papers of this genre to look for something seemingly unique -- some sort of hook -- that'll grab the masses as the silver bullet. One which they can quickly implement in their process (for instance a poorly used and abused bug tracking application, or a hashed out daily build script that has been failing for months but no one has noticed because it has no utility, or partnering up developers in pair programming, or implementing code reviews, or pursuing test-driven development) and claim success. "We score a 9! Awesome!" they gloat, high fiving and then returning to the continuing cycle of project failures.
One common silver-bullet hook these days is the classic "only hire the best!" mantra, and I thought it worthy of special mention.
"Only hire the 2% of software developers!" these advice papers crow. "We ensure that our software is top notch by rigorously putting our interviewees through 19 interviews, by asking clever brain-teasers from How Would You Move Mount Fuji, and then by having them design and implement an embedded operating system on a whiteboard!" This is usually accompanied by a "how to spot a great developer!" listing which could better be described as "How the author would find themselves in a pile of applicants".
This arrogance isn't limited to the authors of such silver-bullet recommendations, though. In conversations and forum threads discussing such a top X% recommendation, one quickly comes to realize that an overwhelming percentage of software developers imagine themselves to be far above the norm -- they themselves conveniently fit that top 2% echelon, they believe, so of course they agree: Let the banks and the IT shops take the other 98% (the duds), because the top 2% are too busy making webmail interfaces and bug tracking applications (as ridiculous as that sounds).
The problem with such a "only hire the best!" proclamation, however, is that it's meaningless from the start -- How do you select the top X%, given that the number of attributes of a software development team member is virtually infinite? How do you quantify prospective talent universally like this given that what really matters to you varies dramatically based upon what you're developing, what fit the developer will be in a team, and how you're going to manage them?
If you're a poor manager and you fail to utilize a talent properly, or if you choose the wrong talent for a particular position, it can be an absolute disaster, or at least a non-optimal situation.
The top 2% in one realm was the bottom 2% in the other.
To draw from personal observations, I've known some remarkably intelligent developers who would absolutely storm a path of success in one type of project, in one type of role, basically designing, implementing, and delivering a remarkable project almost single-handedly. Yet they would wallow fruitlessly for months when put on another project. Whether it was because they had no motivation or passion for the new project, or that they simply couldn't adapt to the new requirements -- which is remarkably common. Great developers, young and old, often have a niche where they are remarkably strong, outside of which they falter -- the results were the same: A great developer was being wasted on a project that didn't leverage their strengths, and a project had a deadweight superstar that couldn't catch on. The top 2% in one realm was the bottom 2% in the other.
There are many projects and situations in which John Carmack and Linus Torvalds would be complete disasters.
There are many who'll disagree with me. "That's hogwash!" they'll say. "I can do anything well, it's just that IIS is a piece of crap, and the MSDN documentation is all wrong, and Microsoft is evil, and there's this strange behaviour with the MSXML Library -- that wouldn't happen on Linux! -- and that really screwed up my timeline, and....". Sure.
Of course this could be countered by claiming that the "top 2%" refers to whatever pet dogma the speaker subscribes to. "The top 2% writes test cases before writing code, comments all code (in RoR of course), and does their timesheets by 4:30pm every day".
And thus it is explained how every developer can claim to be the top 2%, and how every elite-herder can claim to hire only the top 2%: They simply adapt the meaning to describe whatever practices they adhere to, whatever techniques they use, and their personal skillset, or by simply describing the candidates who made themselves available to them, and who accepted the position.
In that way we can all be #1.