tag:blogger.com,1999:blog-115164592011-06-22T06:54:09.375-07:00Dinonoreply@blogger.comBlogger141100tag:blogger.com,1999:blog-11516459.post-29223492043959230502007-09-07T10:55:00.000-07:002007-09-07T16:26:51.567-07:00

I'm totally impressed by the evidence-based scheduling (EBS) proposed by Joel Spolsky and his team. Their approach to scheduling is so simple and usable that people may adventure to try it out. And then there is a good chance that the EBS will make accurate predictions.For accurate predictions, the project has to broken down into fine grained half-a-day sized tasksHuh, is that small print? In all

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-55507596635001030702007-08-31T14:40:00.000-07:002007-08-31T16:32:52.124-07:00

I always break down my code in interface, behavior and implementation. Code structured this way scales up naturally while its dependencies are easy to manage. This breakdown also promotes code testability and reusability. But what always amazes me is that, when the code is structured correctly, one can achieve a lot with very little code. On the negative side of things, the code is fairly

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1160560136114150272006-10-11T02:48:00.000-07:002006-10-11T02:52:25.196-07:00

The Bad:All-in-one interfaces, which address multiple concerns. Such interfaces are likely to change. They force changes in unrelated code. Large interfaces create artificial dependencies.The Good:Segregated interfaces, with only one reason to change. When an interface changes, only relevant code changes.Let's implement a swiss-knife which has a blade, a scissors and a can-opener. As

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1159471911877708072006-09-28T12:30:00.000-07:002006-09-29T09:07:26.973-07:00

The Bad: Making abstractions depend on implementations. Dependencies are inverted, instead of running from implementation towards interfaces they go backwards. The consequences are dreadful: very quickly the code becomes spaghetti like and each change request is going to look like a 9th Richter scale codequake.The Good: Have abstractions dependent only on other abstractions. Have implementations

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1159339250953239182006-09-26T23:34:00.003-07:002006-09-26T23:57:35.866-07:00

The Bad: Diving too soon into implementation details. The end result is a rigid design. Each time a new feature needs adding it’s a major piece of work. The rigidity derives from the fact that the design lacks abstraction.The Good: A good software design contains both abstractions and concrete artifacts. The first are interfaces and abstract classes, the second are concrete classes, also named

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1159234835577255062006-09-25T18:40:00.000-07:002006-09-26T23:09:08.856-07:00

The Bad: Adding a non-public type to the signature of a public type. In order to get the code to compile, the non-public type has to be refactored to public, thus weakening the package level encapsulation. With time, if the same wrong is repeated enough, all classes and interfaces in the package become public. Package level dependencies quickly become unmanageable. All classes in the package are

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1159209435038062602006-09-25T11:35:00.000-07:002006-09-25T14:35:26.203-07:00

Somebody requested me to post some examples of badly engineered code compared to well engineered one. It’s a fare request. Plus, writing about that makes things clearer for me too. It's a good learning exercises to explain why the bad are bad and why the good are good. So, the next few posts will focus on making that comparison.

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1158735790180509462006-09-19T23:50:00.000-07:002007-06-15T12:48:36.786-07:00

A simple interface can take a program a long way. public interface Expression {Expression evaluate();}This can a starting point for an implementation of functional programming in Java. Java has enough firepower to implement functional programming and dynamic typing. Following I've tried to provide an elegant solution to the above problem. The article discusses some of the design issues. The

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1153169889793192952006-07-17T13:57:00.000-07:002007-06-15T12:31:26.345-07:00

In the last 16 years I've done software development for quite a few companies. I've seen good and well engineered code only in a couple of places. The norm is poor code.The software industry requires highly trained people. In almost all cases, senior developers have a B.Sc. or M.Sc. from an accredited university. Self-taught rarely works above the intermediate programmer level. Education is

Dinonoreply@blogger.com1tag:blogger.com,1999:blog-11516459.post-1152226777377393682006-07-06T15:57:00.000-07:002007-06-15T12:32:38.567-07:00

After reading G. Chaitin's book "Meta Math - The Quest for Omega" (summarized in SciAmer ) I realized that in order to completely verify a software system it is required to employ resources which have at least the same complexity as the system itself. Complexity means effort(and that means $$$$), therefore an organization should spend the same effort for verification as it spends for

Dinonoreply@blogger.com1tag:blogger.com,1999:blog-11516459.post-1129247875527770762005-10-13T16:41:00.000-07:002005-10-13T16:57:55.533-07:00

There are three things required to sell a product: functionality, quality and timeframe. You miss any of the three, next you don't have a selling product. In an perfect world, you would plan to cover all three aspects and then manage the development accordingly. In reality you cannot manage all three aspects. That puts hard boundaries on each of functionality, quality and timeframe. The resulting

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1122928228941278662005-08-01T13:29:00.000-07:002006-01-02T20:10:53.690-08:00

A program is a list of instructions. Each instruction is equivalent to a sequence of operations ran by a turing device. We can detail the program in its equivalent sequence of turing operations, which can be encoded as the equivalent turing machine. The output of a turing machine is a sequence of bits. That can be seen, of course, as another turing machine. With that as a prerequisite, can a

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1111733255259788722005-04-24T22:47:00.000-07:002005-04-28T00:42:59.333-07:00

SuperBugs inherit their "intelligence" from the system complexity. It is the system complexity where we have to look for weapons against superbugs. Here are a few things programmers and their managers can do to prevent superbugs from occurring in the code and to bring down the ones that haunt complex systems.SuperBugs inherit their "intelligence" from the system complexity. It is the system

Dinonoreply@blogger.com0tag:blogger.com,1999:blog-11516459.post-1111084100395739042005-03-17T09:54:00.000-08:002006-01-02T19:29:18.946-08:00

The turing halting problem: "Given a description of an algorithm and its initial input, determine whether the algorithm, when executed on this input, ever halts (completes). The alternative is that it runs forever without halting." [ wikipedia.org ] There is no such thing as bug free software. No matter how much quality we try to put into our software, bugs always seem to find their way back into

Dinonoreply@blogger.com0