Comments (0)

By Krishna, September 30, 2008

As an avid player of computer games, I find many of them share some built-in flaws when it comes to playing higher levels in the game.

1. Waste of time at lower levels: To get to a level where the player is challenged, you have to repeatedly go through very simple beginner levels. In many cases, you could literally sleep-walk through the initial levels without failing them. This wastes a significant amount of time, and in addition, prevents you from playing more the game’s more challenging levels. Some games have cheat codes that allow you to jump to a particular level. At the very least, all games should automatically allow you to directly start from a level that you have accomplished at least 3 times and which is not greater than 3 levels lower than the level you failed.
2. Disproportional scores at higher levels: Higher levels offer you more opportunities to score points. This is okay, since the reward is accompanied with greater risk. But sometimes, the rewards are entirely disproportionate. For example, the 31st level may allow you to score twice the score that you attained in the 30th level, which makes a mockery of the score. It is better to end the game before it descends into such illogic.
3. Physically impossible: The best example I can think of is Tetris. Towards the end, the game is a farce as the blocks keep falling faster than you can press the keyboard. Arcade shooting games also fall into this trap. You suddenly have hundreds of enemy objects to shoot at and you are just winging it. This goes back to the previous point where you gain disproportionate points not based on your skills, but just pure physical reactions.
4. Luck playing a greater role: Some games, such as card games, are inherently games of chance. But there are others, like Minesweeper, that award you points based on your reasoning ability. And then towards the end, they present you with choices that have nothing to do with reasoning, but everything to do with luck. You guess wrong, you just threw away the entire game.

These difficulties have no relation with the “fun” part of the game. You can still enjoy games with these problems. I guess, though, if you are trying to create an online game to attract more users, here is why you should be careful:

1. Users are likely to play the game more often if they know that the time requirements are low. That means allowing them to jump to a challenging level directly, instead of draining their time by making them play basic levels.
2. If users look at the best scores and they see large figures (inflated because of disproportional scores) when compared to their high scores, they will make fewer attempts to surpass those scores by playing the game frequently.
3. Users need to feel that they can win. Making the pace humanly impossible makes them less sanguine about improving their scores. Instead of using speed to increase difficulty, use other elements that the user can learn and improve upon, allowing them to clear that level.
4. Guesswork in reasoning games drives away those who think they can master the system. You cannot overcome something that is pure luck.

Each level should provide more challenges and more tricks to overcome those challenges. The way to get the user to keep coming back is to make them realize that if they master the trick and devise a new strategy, they can pass that level the next time.

Comments (0)

By Krishna, September 21, 2008

Justin Etheredge had a question about the strategy for becoming a better developer. There is a simple answer: “Code”. The more you develop, the better you become. So, the bias should be towards finding more opportunities to code, improve code and apply coding techniques and best practices.

You may ask, what about learning? After all, you have to learn various coding techniques before you can apply them. But in reality, the more you challenge yourself with complex development tasks, the more you will be forced to learn. Learning stops being an end in itself, but subject to your programming needs.

Learning, for its own sake, results in knowledge that is a mile wide, but an inch deep. It does not help you solve real problems. It is also likely to be forgotten quickly without the training provided by utilizing it in the work you do. It can also lull you into a false sense of understanding, and lead to bad, under-informed decisions.

Knowledge acquisition should be like waves formed by a pebble in a pond. You should be strong in your speciality and then keep expanding into associated areas such as tools, frameworks, new versions, and dependencies. Obviously, some level of general knowledge about other areas is important, but don’t fall into the trap of over-rating it and spending too much time while neglecting your primary strengths.

But let’s go back to coding. Coding at work offers you the opportunity to code, but internal and external (customer) constraints prevent you from maximizing your learning. The longer you work on the same application at work, the lesser you improve, unless you decide on a technology or architecture upgrade, which is typically infrequent.

So, you must do coding outside of office hours. Choose a problem that you want to solve, so that you remain motivated to complete it. Select non-trivial problems so that you are forced to go outside your comfort and knowledge zones. Once you come up with a solution, see how you can improve upon it. Demonstrate it to others so that you can invite their feedback for improvement as well as encouragement.

Games are a good example of a hobby problem. I once gave a problem to a few students of mine: Create a working chess board that allows two human beings to play a game. This was not spectacularly difficult, because the only logic involved was the rules of chess. But it motivated them to learn graphics and object-oriented programming.

Therefore, make coding (at work and at home) the focus of your attempt to become a better developer. Other activities (reading books/blogs, networking, podcasts) can be subservient to it. As you increase your strength in your core areas, you can expand outwards into more knowledge domains.

Comments (2)

By Krishna, September 7, 2008

From talking cars to androids, artificial intelligence is a very popular theme for movies. It is a very intriguing subject with so many potential (useful and harmful) applications. Many science fiction writers predicted that today (in 2008) we would live in a world where robots do most of the work. Human beings either enjoy the fruits of the robot’s labor or are subjugated by them. Neither is true, of course.

As a layman, I wonder how little advanced technology has delivered on the promises of artificial intelligence. Even though we have made tremendous leaps in information processing and communication, we are not yet at the level where machines have taken over human decision making and creativity. I do not say this to mock or belittle technology in the way some do to suggest that humans have some perfect traits that technology can never conquer.

Rather, I sometimes feel that it is the opposite. Humans are not perfect. They make lots of mistakes. They make unpredictable errors in judgment. They are inconsistent in applying the same rules to similar situations. Not only that, every human being operates from different principles and viewpoints and frequently changes them too. This imperfect and unique human intelligence is cause for both beauty and disaster in this world.

On the good side, we have creativity because every human being thinks differently. Because there are so many of us having ideas and creating things, we sometimes end up with great works of art and improvements in our life. If you create 1000 robots on an assembly line, you get 1000 similar brains operating the same way with the same rules. Instead, you would need a unique brain for every robot with different starting rules and the ability to change their core beliefs, and then you need a whole lot of them with no guarantee that you will produce something beautiful.

On the bad side, human beings are responsible for car crashes, stock market bubbles, and prescription errors on the basis of poor decisions. Technology can improve decision making, but it cannot entirely avoid mistakes in a real world. Technology cannot predict and prepare for every possible future scenario. It may not have any similar past situation it can rely on for making a correct decision.

In a situation where a negative outcome, however improbable, can be grievous harm or death, what users would trust technology? Consider that you may be willing to let your car parallel-park, but would you be ready to trust it to drive automatically on the road? What company would be ready to release such a product and face the inevitable legal consequences?

We understand human deficiencies in processing information. If you ask a person to do something, there is a significant chance that they will misunderstand it, forget it or do it incorrectly. That is the main reason we have standards, documentation, testing and so on. After their birth, human beings take several years to become functional and they are not even trusted to make important decisions until they are 18 or 21. Many organizations do not even trust their adult workers to make decisions.

So, when we imagine AI robots, what are we talking about? Do they come out of the factory packed with a 21-or-more-year-old adult brain? What experiences do they base their decisions on? Do we trust them to make choices for us? Do we debate with them? Do they have any moral or ethical base to make decisions on?

Raymond Kurzweil, an inventor and popular AI writer, suggests in one of his books that in the future, we would have the technology to scan a human brain and recreate it. I wonder if it is any different from cloning aside from the biological difference. After all, you may be able to have an interesting conversation with this electronic brain, but you would not gain anything with respect to improved creativity or judgment.

Comments (0)

By Krishna, September 6, 2008

software development on new applications is only a fraction of maintenance work on existing applications. But almost all the conversation and writing on software tends to revolve around building new software – architecture, design, standards, code samples, etc. The consequence of this mismatch is that planning for software maintenance is often done as an after-thought and in very short-sighted terms.

After the release of a new software project and the immediate support needs, the project team is slowly starved (or sometimes, suddenly deprived) of resources that are pulled away into other immediate concerns. Less qualified developers are allocated to work on periodic bug requests. Inside the organization, working in the project is viewed as a career dead-end and developers try their best to avoid getting assigned to the project.

There is no surprise about what comes next. The product slowly falls in disfavor with the users. They start finding faults with it, calling it non-user-friendly, confusing and complex. Training does not seem to help, even (or especially) with manuals weighing several pounds. Finally, management calls it a day and starts on a quest to build a replacement from scratch, or buy or rent a new tool. This repeats cycle after cycle.

Throwing away outdated equipment and building/buying a replacement is not essentially a bad thing. That is what we do with automobiles, furniture, kitchenware and so on. But software is more malleable. And often, the money spent in replacement is much greater than the effort it would have taken for proper maintenance, not to say anything about avoiding the frustration of end users working with the increasingly obsolete software.

Like tangible products, software products also decay. They do so because the environment around them keeps changing. The rules of the business change. People’s expectations about user interfaces change. The increased quantity of data and number of users requires performance tuning as well as better physical resources. The quality of data also brings new challenges of organization and reporting. Superior technology makes the existing architecture and design outdated. New security threats appear.

The more successful and established an application, the faster it will decay. Having more users means greater expectations as well as a multitude of differing views about what the software should do and how it should behave. Therefore, maintenance requires the same or greater level of resources that went into building the application in the first place.

If the success of the software is directly translated into revenue, allocating necessary resources is a no-brainer. However, when a company falls well behind the market leader, continued investment is not enough to catch up to the market leader, because there is not enough revenue. It is better to target a niche market at that time. Another mistake is by the market leader who decides to reduce investment and “milk” the market, thus allowing competitors back into the game.

When it comes to internal corporate software though, there is no revenue to feed the maintenance needs. Since only the costs of maintenance are visible, the trend is towards starvation, not more resource allocation. One suggestion I have is to spin the product team off as a separate organization with a profit motive and with the intent to supply software to the parent organization. If there is better software elsewhere at a similar cost, the child organization would cease to exist. Hence it has the motivation to continue to maintain and improve the application.

Although the idea of having a separate company for the sole purpose of writing software for one organization may seem ludicrous, there are many companies doing exactly that, serving a single entity, such as the federal or state government, the military, schools or Fortune 500 companies.

Dealing with an external entity forces the organization to build or choose the right software. The external organization is in charge of managing its costs and revenues. Its developers are more motivated since they can see the financial results of their efforts. There is no question of moving them to some other priority inside the main organization. Overall, a win-win.