There are some things a good developer is NOT required to know

Jeff Atwood and Peter Norvig seem to think you must have a deep understanding of how computer hardware works to be a good software developer:

Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk

I did learn these things, but after reading Jeff's post I have been trying to remember a project I worked on during the past 10 years which required this type of knowledge - and I got nothing.

Let's put aside for a moment specialized area in software development in which this knowledge is important:

• Real time applications
• Embedded applications

Assuming you are developing using a modern, high level programming language like Java or C#. During development of applications in areas not mentioned above, did you ever encounter an actual need to know these things? why?

Good team developers are cameleons

Jeff Atwood thinks regions are evil:

No, I will not use #regions. And no, I DO NOT NEGOTIATE WITH TERRORISTS. Shut up.

I tend to disagree. I like being able to navigate through code blocks by scanning them and not using incremental search.
Besides, you can always expand all regions in code using a keyboard shortcut, and if it really bugs you, simply do a replace of "#" with "//#" and your problem is solved (until the next guy does the opposite).













However, I do agree with Jeff about working with a team, and that's why I think feeling that strongly about any coding habit is wrong.
Whenever I go into a new project I try to adapt my coding style to the existing style, even if initially I don't really like it.

That's why I don't think you should feel that strongly about anything and fighting about coding habits is useless - a good developer can adapt to any working environment.

Non-agile design and NIH

During a design meeting of a new project the issue of performance is raised.

This is the theoretical (worst-case scenario) performance requirement:

As existing frameworks and 3rd party tools don't match these requirements, new frameworks will be developed.

After spending many men-months on developing new frameworks (even before the development of the application itself) this is the application's performance:

Eventually the application is shipped, and customers are satisfied with the performance.

However, this is the average case performance requirement:

(NIH = "not invented here", a common syndrome in the software industry leading to spending resources to create new tools instead of using existing ones)

Throw Exceptions Responsibly

Recently I had to spend some time to fix a crash in the application I'm working on: I kept getting an OutOfMemoryException with no relation to the amount of free memory on the computer.

Eventually I found the bug: turns out the DrawArc method doesn't like to be called with a very small angle, so it goes BOOM.

Another tidbit I found while searching for the cause was the fact this behavior is not unique to this method:

"The thing I can add about this is that GDI+ tends to throw OutOfMemoryException when something else is going on. I've seen people complaining about this in the newsgroups and elsewhere on the internet.

So we have here a framework with the habit to fail very un-responsibly.

Hmm, why does that sounds familiar?

Somehow I get the feeling that while Microsoft employ 50 people to handle a single feature, no one is left to take care of exceptions and errors in their products.

(in the photo: Windows Vista security exception)

.Net Performance Pointers

After going this week to the Microsoft performance open house, here are few things to consider:

• Create performance counters of your own to measure various statistics.
• Try to avoid using interfaces and virtual methods to supports inlining.
• If you use a "Contains" method of a collection on structs, be sure to override the "Equals" method, since the default Object.Eqauls method used boxing twice - once for the parameter and the once for "this".
• Similarly, you should override the GetHashCode methods for structs, since the default implementation for a struct is very inefficient.
• Use Perfmon.exe to monitor the "% time in GC" - a high value may indicate mid-life crisis.

The Problem With Crutches

Coffee is good for you, as long as you don't drink too much.
But how many of you can't pass the day without drinking too many cups?
How many of you are addicted to coffee?

In the recent bloggers meeting in Microsoft Israel I complained about the pain it is to add a picture to a blog post using the Community server.
The reply?
"Why don't you use Live Writer to publish posts instead of the online control panel?"

In a recent post Doron wrote about his love for ReSharper:
"I honestly can't work without it anymore. It has changed the way I code, and I will never attempt a serious refactoring without it"

There are many great tools out there that can make you more productive. No argument about that. The problem starts when you become dependant of those tools.

That's the problem with crutches - if you ever lose them, you become handicapped.

David Platt on Why Software Sucks

I went to a lecture by David Platt on the subject of "Why software sucks", which discusses what is wrong with software today (hint: it's mostly designed by programmers) and how we can improve it.
From listening to a previous ARcast with him I already knew he is a very entertaining speaker, and he proved me right (in fact, I kept thinking I could bring my wife to one of his lectures and she would have enjoyed it as well).

David began his presentation with a screenshot from the Better Business Bureau in the US, listing complaints by industry, and the amazing thing about it - people dislike software more than they dislike used-cars salesmen!

The main idea of the presentation (backup up with all sorts of amusing anecdotes):

• People don't buy software for the sake of the software itself - they buy software to get something done. They are not interested in using the software, they want to have used it.
• Programmers tend to design software for people like them, while most users are very different.

Platt's solution resolved around 5 key points:

1. Add a virgin to the team - add someone to the team with zero knowledge about the inner workings of your software.
2. Break convention if needed - don't behave in a certain way just because all every application behaves the same way.
3. Do not let edge cases complicate the main stream - extra features aimed at edge cases complicate your software and make it counter productive.
4. Instrument (Carefully) - Try to gather information about the way users use your software without harassing them.
5. Question each decision - ask if each decision is taking your project closer to the result or further away from it.

The lecture itself was followed with a Q&A session, in which I asked him a question (which landed me a signed copy of his book - thank again, David!):
If programmers are so bad at designing UI, why not bring in a specialist to do it?
His response (after correcting me for saying "Graphics designer" instead of "User interface designer") was it's actually a good idea, since most of the industry is already headed for specialization in various subjects.

I found another podcast on ITConversions network, and here are two short videos from the presentation:

Three wrong assumptions

Did some blog reading today, and found out several assumptions I had which were wrong:

• Assumption: "Protected Internal" means both protected and internal
  Wrong: It means Protected OR Internal.


• Assumption: 32bit Windows is limited to 2/4gb ram
  Wrong: It's limited to 2gb of ram per application.


• Assumption: OpenFileDialog is harmless
  Wrong: It loads a mini-explorer, including all the extensions you have installed.

Every n matters

When you study computer science and you start learning algorithms, you are introduces to the O(n) concept, meaning there is a different between an algorithm that takes linear time (1 second for 1000 items, 2 seconds for 2000 items and so on) and an algorithm that takes exponential (2 to the power of n) time, meaning it's a very inefficient algorithm.

Although this lesson is important, there is a darker side to this kind of thinking - you tend to ignore efficiencies with the same order of magnitude, meaning an algorithm with 10n efficiency and 80n efficiency are the same to you, even the first is 8 time faster than the second. This means that if you choose the first a certain procedure may cause the user to wait 250 milliseconds, while the second will delay the user for 2 whole seconds - big difference.

So don't consider to n values to be similar just because they are within the same order of magnitude.

Tainted if you do, tainted if you don't

Microsoft's latest move, to release the source code for the .Net framework, has triggered a variety of reactions due to the licencing model used in this release.

Frans Bouma thinks that looking at the source code makes you liable to legal action:

Take for example the new ReaderWriterLockSlim class introduced in .NET 3.5. It's in the System.Threading namespace which will be released in the pack of sourcecode-you-can-look-at. This class is a replacement for the flawed ReaderWriterLock in the current versions of .NET. This new lock is based on a patent, which (I'm told) is developed by Jeffrey Richter and sold to MS. This new class has its weaknesses as well (nothing is perfect). If you want to bend this class to meet your particular locking needs by writing a new one based on the ideas in that class' sourcecode, you're liable for a lawsuit as your code is a derivative work based on a patented class which is available in sourcecode form.

Phil Haack partly disagrees, and sees no problem as long as you exercise caution.

I think both of them may be missing another side of this mess:
Suppose you read the source code, and some time later, after you forgot all about it, you write your own ReaderWriterLock which violates Microsoft's patent.
Now, the hotshot lawyer working for Microsoft has no way of proving you read the source code prior to writing your implementation - but he doesn't need to. He only needs to claim that since your code works in a similar way to the MS code, and since MS code is already out there, it's highly probable you read it.

In other words, this move gives Microsoft an extra advantage in future patent lawsuits, even if no one reads the thing.

The conclusion: read the source code, even for the single purpose of being sure your code doesn't violate any patent.

(thanks to dbraaten for the photo)

Working with a remote development team

Some times you have a remove developer/team working on the application, as well as in-house team, and they can't use a remote connection to your source-control solution.
I found out these methods help:

1. Check out files for them to work on in advance, keep the files checked-out until they give you the updates.
2. Have the remote developer save the original file for comparison (if merge is needed).
3. Have the remote developer keep a list of changes.

What else do you recommend for this situation?

XP and Scrum

In one of the companies I worked at I introduced TDD into the development cycle.
This was not done as a part of adopting it as a part of a complete methodology, but as a singular concept.
Later, when the company switched to Scrum, we also incorporate ideas like daily build (you don't have to go all the way to continuous integration) and simple designs, but never as partial concepts from the XP methodology.
I read Jeremy Miller's post about the combination of Scrum and Extreme programming, and I think the reason Scrum as a complete methodology is more accepted is that there are some concepts in XP that tend to scare people (like pair programming), while Scrum a more of a natural evolution of the work process.
As Jeremy wrote, both methodologies cover different aspects of the development cycle, but I think that while people will keep adopting specific ideas from XP, Scrum as a complete system will be more successful.

One developer, 2 servers, over 50 millions page views each day - using ASP.NET

I have read Oren's post, in which he writes (again) why he thinks Asp.Net is a bad web platform.
I have been reading about various tools like Ruby or MonoRail and people promoting over using simple Asp.Net.

Coincidentally, I have recently listen to an Arcast episode with Markus Frind, the founder of http://plentyoffish.com/.

This dude is the only employee in the "company" (acting as the developer, architect, CEO, janitor, etc), running the web site on two servers from his home. He wrote the site as a programming exercise.

And why is he using Asp.Net?
"Well I use ASP.NET now because it’s trivial and easy and gets the job done. There is just so much to learn out there and every six months it completely changes. So I stuck with what I knew, used it a lot, and I’ve gotten really, really good at it. "

It's beyond me why Microsoft doesn't make him their spokesperson for their platform.

Manage your project with your developers

I have read Udi Dahan's post on letting someone other than developers manage the project, and disagree with him on several points.

Udi starts by stating "Developers don’t know how to estimate".
He than "backs it up" with the explanation of the fallacy of an estimation to the distant future:
"For example, if the estimate is a day, you can expect it to be finished in around a day. If the estimate is a week (5 works days), it will probably vary between 4-10 work days. If the estimate is a month, in all actuality the developer probably doesn’t know enough to say but will answer when pressed."

He than suggest this approach: "The difference is that by working based on features, and measuring project progress by feature-units completed per iteration, I drive down variability"

Sounds Agile to me.
But I fail to see where does "don't let developers manage the project" fit in this statement.
If you work using an Agile methodology, you make estimates based on small units of work, and are able to adjust the course of the project as you go along. This has everything to do with methodology, and nothing to do with the qualifications of the person managing the project.

There may be reasons for not letting developers manage projects, but this is not one of them.

Creating a considerate software

I read Jeff Atwood's post on how to handle software errors, and I agree with the concept of not harassing the user with useless error dialogs (while writing the error in the log file, of course).

After reading a related post on considerate software, I was a little amused to read this comment to the first post:
"Network BDE/Paradox apps corrupt data all the time - it's our number one cause of support calls. I'll be glad to be rid of it."

During one of the previous jobs, I worked at a very small account software firm.
The application was written in Delphi, using Paradox as a local (tabular) database.
Paradox is a great database for small application, since it's very fast (especially compared to Access, the main competitor in that scale of uses), but it's table get corrupted sometimes (mostly from using it across network drives or from unexpected shutdowns).
Most of the times it's not an actual data corruption, but index/header corruption, in which the table can be safely rebuilt.

So I found a library specializing in Paradox table repair, took the time to study it, and added a mechanism during the application start up to automatically verify the database and fix it if needed.
Only when the failure of the data was catastrophic I notified the user, and even than a possible solution could have been daily automatic backup (I can't recall if I implemented this feature).
This feature reduced the number of database related support calls by 80-90%.
So if the commenter is still receiving many support calls, I'm not sure his software is very considerate.

Career paths for a software developer

Suppose you have been a software developer for few years, you know your technology, you are good at what you do - but what's next?

Looking for answers I found a great post, titled "Why a career in computer programming sucks".

The author, John Bennett, Jr., lists reasons why it's a tough profession:

1. Temporary nature of knowledge capital - The technology you know now will be worthless in a few years. Mature developers have no significant advantage over younger developers.


2. Low prestige - The average person doesn't really know any famous programmers. You can name BillG, but people know him because he is a billioner. Just try asking someone on the street who Linus Torvald is.


3. The foreignization of computer programming - More and more jobs are outsourced to foreign countries and/or cheap workers (even is Israel).


4. The working conditions suck - The average employer is contended to dump developers in an open space, and have them fight for decent hardware, although the developer cost much more than any hardware upgrade.

In other words, you got to love this profession to be in it. But love alone won't protect you against foreign outsourcing or age issues.

So what are your choices?

1. Software Architect


2. Systems Analyst


3. Management (usually starting with a team leader position)


4. Project Management (you don't really manage anyone, it's more related to a sales position)


5. Self employed (Freelance developer, Consultant, Startup founder)
   
6. Specialist / Guru (MVP, consultant, etc)

Alpha geeks and Morts

I have been reading for the past month or so a large number of blog posts dealing with Microsoft's lack of respect for "Alpha geeks" and the inferiority of "Mort" type developers.
I already objected in the past to some of the places this superiority complex was taking some developers, mainly the idea that those "Alpha geeks" somehow lead the developers community toward a brighter and better place.

So I decided to check out the original meaning of the phrase, and guess what I found:
Tim's view was that alpha geeks, as a whole, are leading indicators.
In this context, at least, it doesn't necessarily indicate that the alpha geeks are the best technologists - someone who is very expert in a particular technology but doesn't look for new stuff wouldn't fit. "Alpha" also has connotations of superiority and dominance that also don't necessarily fit. The point in this context is that alpha geeks are the people who like to explore and try new things.

Not leaders (as the "Alpha" term implies) and not master technologists - only market indicators.
If we use this meaning, Microsoft shouldn't build software to address those people - it just need to study their behavior and respond as it sees fit.

And that brings us to "Mort".
The fact is most "Mort" type developers get their job done. Maybe they don't write the most beautiful code out there and they like to use wizards - but that doesn't mean they write bad software.
Maybe we should add the "humility" attribute to the "Alt.Net" developer's list of qualities.

Is it ok to make mistakes?

I was listening to an Arcast episode, which was a recording of an architect panel recorded in Israel, and I heard this:

"I think when I talk to people about what makes a great architect, the number one thing I hear from people is "Experience." Well, what makes great experience but making big mistakes and learning from them, right?"

That got me thinking.

You'll never hear a doctor brag "I have great experience, I killed 60 patients over the years", or a building architect saying "I have great experience, 3 of my buildings collapsed".

So why do software architects feel it's ok to list failures?

I remember several cases in which a building architect was brought to charges because a building collapsed, yet I can't remember a single instance in which a software architect/lead developer was help accountable for something like that.

Is it because software errors don't kill people?

But there today hospitals run of software, airports use software, traffic control is managed by software. It's safe to assume a major bug in a critical application can cost lives.

Is it because the person that caused the error is not around when it occurs?

But the same logic goes for a building architect.

I think it's because the software industry is not mature enough, and somehow the general public adopted the same approach.

What do you think?

Agile in the real world

Let's suppose you have been saving to buy a new apartment, and you approach building firm as the building is still being build. The sales person says: "The building should be finished in two years. However, we just started working with Agile methodology, so we can't promise you windows, doors or a sink"
Would you pay your life's saving to this person?

But that's what Tom Hollander suggests: "Nobody should promise exactly what will be delivered at the end of the project"
I have recently listened to a screen cast dealing with Ruby On Rails, and it began with similar explanation of what is Agile development, leading to the same conclusion.
I'm a big fan of the Scrum method, which is Agile, but only when it comes to the way the team is working together.

Most developers I've met know the exact specifications of a computer before they buy it. They know the various systems in the car they intend to lease or buy. They know the exact contrast of the LCD TV they just purchased.
But when it comes to software, they claim "specs is speculation".

Wrong.
Specs is specifications, and that what's brings in the money.
A customer is expected to pay huge sums of money - of course that customer requires some sort of a promise, in the form of specs.
Saying "I can't promise exactly what you'll get for your money" can only work with open source projects, not in the commercial world.

You may use Agile to modify milestones along the way, but you need to commit to an end result.
Just imagine your customer saying: "well, I can't promise exactly how much money will be delivered at the end of the project".....

Web developers - the only that matters?

I have read Phil Haack's post a week ago, and I have been thinking about it since then.
Phil wrote:
"But when you think about it, games and operating system kernels make up a very small percentage of all software being written today. In terms of public interest and buzz, building software for the web appears to be the only software development that really matters."
In other words, let's ignore all those pesky developers working server side, web services, winforms applications.
They don't matter because they don't develop software for the web.

Oooookay.
Sorry, I can't agree with a single word in that statement.
I think the problem starts with Phil's definition of "Alpha Geeks".
Let's use for a minute his view that an Alpha Geek must be ALT developer:

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principles (sic) and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principals (e.g. Resharper.)

But ALT developer doesn't necessarily use OSS tools, he may just be taking ideas from OSS tools to implement in MS environment.
I think I can call Anders Hejlsberg (invented C#) "Alpha Geek", and he had nothing to do with web software. He may be considered ALT developer, since he took current (Java) ideas and formed a new language based on them.
In fact, based on that definition, I can claim the entire P&P team in MS are ALT.Net developers, since they keep taking new concepts from outside the conventional MS world and using them.
So ALT developer <> web developer.

But I think Phil's entire view of "Alpha Geek" is wrong - it has nothing to do with ALT devs.
Let's view the biology definition of "Alpha" (from Wikipedia):
In social animals, the alpha male or alpha female is the individual in the community whom the others follow and defer to.
In other words, "Alpha Geeks" are leaders of the geeks community.
Being a community leader has nothing with web development.
Scott Hanselman records a great podcast. Joel Spolskyis a talented writer. Jeff Atwood writes about the people writing software.
Each one has thousands of readers, and the reason they are popular has nothing to do with web development.