comparing two software implementations

how would you compare two software implementations, where one is based
on proper domain objects and abstractions, and another one hides
complexity by just providing a way to generate code that you have to
repeat through some kind of configuration files, etc.

many thanks in advance.

v4vijayakumar <vijayakumar.subburaj@gmail.com> wrote:

> how would you compare two software implementations, where one is based
> on proper domain objects and abstractions, and another one hides
> complexity by just providing a way to generate code that you have to
> repeat through some kind of configuration files, etc.
>
> many thanks in advance.

I would use man-hours. Not just the man-hours it takes to create each
solution, but the man-hours it takes to modify them.

Daniel T. wrote:

> v4vijayakumar wrote:
>
>> how would you compare two software implementations, where one is based
>> on proper domain objects and abstractions, and another one hides
>> complexity by just providing a way to generate code that you have to
>> repeat through some kind of configuration files, etc.
>>
>> many thanks in advance.
>
> I would use man-hours. Not just the man-hours it takes to create each
> solution, but the man-hours it takes to modify them.

Said solutions are not complete without their unit tests.

I routinely reject systems - even up-and-coming ones with a lot of promise -
because they were not created under test, and they are impossible to test-first.

--
Phlip

Phlip wrote:
> Daniel T. wrote:
>
>> v4vijayakumar wrote:
>>
>>> how would you compare two software implementations, where one is based
>>> on proper domain objects and abstractions, and another one hides
>>> complexity by just providing a way to generate code that you have to
>>> repeat through some kind of configuration files, etc.
>>>
>>> many thanks in advance.
>>
>> I would use man-hours. Not just the man-hours it takes to create each
>> solution, but the man-hours it takes to modify them.
>
> Said solutions are not complete without their unit tests.
>
> I routinely reject systems - even up-and-coming ones with a lot of
> promise - because they were not created under test, and they are
> impossible to test-first.
>
I try not to reject anything for one reason or another. The only thing
that would get me to reject a solution is finding a better one.

The question I hear all the time: "Is it possible to do x". The answer
is always "yes", sometimes it is "yes, but it would be ugly and take too
long". Working in a system without unit test tend to fall under the
latter, but that doesn't mean it can be ignored.


--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:

> I try not to reject anything for one reason or another. The only thing
> that would get me to reject a solution is finding a better one.

I'm going to invent an awesome new software library. Would you like to use it,
for some amazing outputs?

Oh, except it uses EBCIDIC, not ASCII, for its source and inputs. You must
adjust all your tools to use it.

Would you like to use it now?

--
Phlip

Hi Vijay,

v4vijayakumar wrote:
> how would you compare two software implementations, where one is based
> on proper domain objects and abstractions, and another one hides
> complexity by just providing a way to generate code that you have to
> repeat through some kind of configuration files, etc.

The 2nd implementation might be preferred if it is not going to have
any modifications/enhancements/maintenance, etc. and development time
is critically important to your project's success and you want to save
money by carrying out development very fast. In such conditions, I
would say that you might prefer the 2nd approach. However, you would
face extreme problems if you want to maintain/enhance/extend the same
solution some time later in the future. In the absence of accurately
identified abstractions from the problem domain and a solution
consisting of completely implementation-specific code, it would be
very difficult for future programmers to actually maintain the
software. Further, such a "generated" solution might very likely
result in code that doesn't separate the implementation from the
interface. So, in case you run into performance problems, you're
likely to carry out a complete re-write of the solution - just for
performance reasons. This is just what came to mind immediately. In
any case, I would prefer the 1st approach - always - unless the
solution is about a very small application which is not going to be
extended or modified or maintained.

--
Asif

Ponka Jhonka wrote:

> Further, such a "generated" solution might very likely
> result in code that doesn't separate the implementation from the
> interface. So, in case you run into performance problems, you're
> likely to carry out a complete re-write of the solution

If your own code has wall-to-wall unit tests, and if you start to dislike your
first solution (A), you can replace it with the second solution (B) like this:

- clone a low-level test that calls code that calls A
- rename your code to code_too, and make it call B
- repeat with another low-level test

When you replicate the entire call stack over A, producing another one that
calls B, you can trivially remove A's call stack, rename all the "code_too"
methods to "code" methods, and retire A. Now your program calls B.

At any point you can integrate, deploy, even release. Nobody needs to know the
code has an extra, latent B system, waiting to emerge.

Put another way, wall-to-wall unit tests, and widely decoupled code, make your
up-front decisions less important. You don't need to attach A to your program by
carving its code into solid marble. If your code is safe to change, then you can
vet A at the same time as you are delivering working features.

--
Phlip

On 26 Jul, 16:51, Phlip <phlip2...@gmail.com> wrote:
> Daniel Pitts wrote:

> > I try not to reject anything for one reason or another. *The only thing
> > that would get me to reject a solution is finding a better one.
>
> I'm going to invent an awesome new software library. Would you like to use it,
> for some amazing outputs?
>
> Oh, except it uses EBCIDIC, not ASCII, for its source and inputs. You must
> adjust all your tools to use it.
>
> Would you like to use it now?

depends if it did something useful for me. If I have a requirement
to process EBCIDIC data *now* and the program exists. Well, yes
sure why not? If i/o is required in ASCII then it might still
be useful- you data convert before and after. If there are no tests
and a change is required it *might* still be useful. As an initial
requirment and test data generator.

--
Nick keighley

Nick Keighley wrote:

>> Oh, except it uses EBCIDIC, not ASCII, for its source and inputs. You must
>> adjust all your tools to use it.
>>
>> Would you like to use it now?
>
> depends if it did something useful for me. If I have a requirement
> to process EBCIDIC data *now* and the program exists. Well, yes
> sure why not? If i/o is required in ASCII then it might still
> be useful- you data convert before and after. If there are no tests
> and a change is required it *might* still be useful. As an initial
> requirment and test data generator.

I really doubt you would pick a library - one that did not _need_ EBCIDIC -
whatever its benefits.

My parable is not about a library without tests (though that's still a strike
against it). It's about one that _resists_ tests - that makes adding them
impossible. That's kind of like breaking my existing tools, the same as EBCIDIC
would make me learn a new editor.

Think Lotus Notes, or Visual Basic Classic.

--
Phlip

On 28 Jul, 12:37, Phlip <phlip2...@gmail.com> wrote:
> Nick Keighley wrote:
> >> Oh, except it uses EBCIDIC, not ASCII, for its source and inputs. You must
> >> adjust all your tools to use it.
>
> >> Would you like to use it now?
>
> > depends if it did something useful for me. If I have a requirement
> > to process EBCIDIC data *now* and the program exists. Well, yes
> > sure why not? If i/o is required in ASCII then it might still
> > be useful- you data convert before and after. If there are no tests
> > and a change is required it *might* still be useful. As an initial
> > requirment and test data generator.
>
> I really doubt you would pick a library - one that did not _need_ EBCIDIC -
> whatever its benefits.
>
> My parable is not about a library without tests (though that's still a strike
> against it). It's about one that _resists_ tests - that makes adding them
> impossible. That's kind of like breaking my existing tools, the same as EBCIDIC
> would make me learn a new editor.
>
> Think Lotus Notes, or Visual Basic Classic.

please don't make me do that

--
Nick Keighley