Mainfram Reality


Archive for February, 2008

links for 2008-02-29

No comments

Microsoft ASP.NET 3.5 Extensions Preview

I have been following the Microsoft efforts to introduce Model-View-Controller wikipedia pattern to the ASP.NET framework. Here is a great introduction describing what they are doing.

Microsoft ASP.NET 3.5 Extensions Preview

No comments

Running Ads one an Ajax site

I have noticed that google adsense ads on top of this blog do not get as many refresh points as I would expect. That is because I use AJAX wikipedia on this blog and each time an article is displayed it does not actually refresh the page, and therefore does not refresh the google ads on top.

I’ve done some research on the issue and here are a few websites to read.

Kevin Cho wrote a post on jGuru describing a workaround solution:
How to advertise on a pure AJAX application?

Ajaxian has an article on the issue as well:
How to Run Ads with Ajax

Eric Picard wrote an article on ClickZ.com talking about this very issue:
Ajax Counting Nightmares

Google Adsense Terms and Conditions

No comments

Software Development, the real story – part 1

Software development is one of those engineering endeavors that does not follow all the general engineering rules. Perception is everything and unfortunately software development is probably the most customizable of all the engineering disciplines. Software can do anything, if budgets and time are limitless. Other engineering branches are a lot more restrictive.

Here are a few simple truths about software development that I have found, through my experience.

  • Software is never finished. Even notepad got an upgrade few years go.
  • The most creative part of software development process is at the end, when users start using it.
  • Uncertainty is certain.
  • Anything is possible, given time and budget.
  • Clients and managers want certainty, they demand it.

These are pretty broad statements, which means that starting a software development process is not easy, and it certainly is the most uncertain part of any project. But almost all the time, even with all this uncertainty, we are asked to develop quotes and time lines pretending the world is certain and what ever we decide today is going to be true tomorrow. These decisions are just not made by software developers and designers, but by clients as well. Even the simplest software can be updated and enhanced in many different ways and greater the user base more opinions and requirements must be considered. So a question must be asked, why bother with set time lines that go for weeks and months. The answer to that question is simple, we should not do it, ever. Small steps, small decisions and ability to change, and change quickly. Agile methodologies dictate this kind of approach, but I don’t want to get into benefits of one philosophy over another, I want to concentrate on common sense.

Let us examine what happens when a client requests a fixed price project that is longer then a coupe of weeks. First thing that happens is software designers lock in functionality and the way software will be written. The creative part of the process happens at the beginning and since the project is set (time, budget, resources) and creative endevour on part of software developers will almost always result in more cost to the project. Since the project is fixed budget, time and resources those types of changes to the design, no metter how creative need to be approved by the client, documentation needs to be written and finally a creative change that would have cost client 3 days of work suddenly is costing them double that. In this type of environment, developers are going to think twice about suggesting these changes and many times the clients will simply reject them as being outside the budget. Let us not even contemplate what this must look like to the client, we found a better way of doing something we already quoted on. Software developers understand that things change, but clients do not, because we told them fixed budget, time, resources project is ok, we accepted it. At the end of such a project the users get to see the system and again any changes need to go through a complicated process before they are implemented. All these restrictions mean the software at the end is not going to be as good and as usable as if we just let the decisions flow freely, had a time and materials budget and each phase of the project was only a week or two long. Every week users get to see something delivered and get to comment. Client gets exactly what they want software wise and software developers get paid for doing what they do best, writing software.

That is it for part one, part two will come is a couple of weeks. I want to research some strategies on how to get clients to accept uncertainty and how software developers can help them in the process.

No comments

links for 2008-02-28

No comments

Next Page »