Re: WebCup 2015

From: Vy-Shane Sin Fat <shane_at_node.mu>
Date: Tue, 26 May 2015 00:32:10 +0800

On Mon, May 25, 2015 at 5:19 PM, Dhiruj Rambaran <dhiruj_at_shoponline.mu>
wrote:

> I think the level and depth of (software) engineering required all
> depends on what the project is all about. Is it a website for a Tabagie?..
> or a Tabagie who hopes to be bigger than Intermart one day?, or are they
> Intermart themselves? Also how much is the guy willing to pay? Rs 2000?..
> Rs 10,000?.. or is the client willing to pay Rs 3000 but with view to pay
> more later when they're intermart?.. or will they not expect to pay
> anything even if they became an intermart one day?
>
> It can be a tricky business measuring all these variables.
>

Agreed.

You are half right Nadim when you say a developer must think like a
> businessman. Vy-Shane is also right re: bad engineering will (can) cost
> more later. The fact is you need to balance BOTH and the ratio between one
> and the other is based mostly all the variables I mention at the beginning.
>

There's a difference between bad engineering and the level/amount of
engineering that is put in. It's good engineering to build a static site if
a simple solution is appropriate. It's bad engineering to build a cluster
where a simple static site would do.


> A (pure) developer finds it very hard to sacrifice quality. They're geeks,
> purists and would rather hang themselves than spout out bad code. In fact
> it's because of this there are so many arguments between the
> client/business and developers/geeks. The business just wants "a program"
> that does the job, does it fast and they save money somewhere along the
> line.
>

Yes, at the end of the day it's better to ship something than nothing,
provided that we can live with the consequences. So, a program that
sometimes crashes might be okay. A program that sometimes causes data loss
is probably not okay. A program that sometimes administers the wrong dose
of medication is definitely not OK!

However, there's a difference between software quality and code quality. I
contend that we should not sacrifice code quality - simply because that's
bad for business. We may ship software that has defects because we've run
out of time and budget to hunt down some known bugs. We've looked at the
issue tracker and we've decided that we can live with what we've got.
That's a different proposition from knowingly writing bad code. There is no
business case to be made for writing bad code. Writing bad code doesn't
speed up a project. It slows it down.


> Academically we like to stick to standards etc.. .but in real world
> business, it's all about "who pays your salary"?
>

Civil and mechanical engineers are lucky because they can point to the laws
of physics and say - "Sorry, we can't compromise on this specification. Not
if you want the building to stand 100km/hr winds. However, we can remove
five floors and that will bring the budget down."

With software we often deal with intangibles. A good engineer knows what
can be sacrificed and what shouldn't be. And a smart business listens to
its experts.



> Just my personal opinion
>
> Dhiruj
>
>
>
> On 25/05/2015 12:45, Vy-Shane Sin Fat wrote:
>
> On Mon, May 25, 2015 at 4:07 PM, Mohammad Nadim <nadim.attari_at_gmail.com>
> wrote:
>
>>
>> On 25 May 2015 at 11:21, Jochen Kirstätter <mscc_at_kirstaetter.name>
>> wrote:
>>
>>>
>>> The whole rating process is based on *the client's / visitor's point of
>>> view*.
>>>
>>
>> +1 +1 +1 (many pluses) to you JoKi.
>>
>> I've always told my collegues, especially Nirvan, with whom I do some
>> freelancing when time permits, that you should not think like a developer
>> but like a businessman + understand the clients' requirements. We are not
>> at school to get A+ for writing outstanding codes. We are here to (1) make
>> the client happy (2) provide something that won't make the client lose
>> money (3) we make money as a developer/"businessman." At the end of the
>> day, it's all that matters. <rude>fsck standards, fsck coding conventions,
>> fsck software engineering, fsck etc...</rude>
>>
>
> I hope that you are being facetious.
>
> Good engineering isn't optional, period. Bad engineering will definitely
> make the client lose money once the software sinks under its own weight
> because it's too hard to make changes to it. Your client may not know or
> care, but you should know better and should care. Software projects are
> always evolving, and you can't take the short-sighted approach that you'll
> throw it over the wall at version 1.0 and be done with it.
>
>
>
Received on Mon May 25 2015 - 16:32:45 PST

This archive was generated by hypermail 2.3.0 : Mon May 25 2015 - 16:36:05 PST