Hi Vy-Shane...
my comment below in italics...
On 25/05/2015 20:32, Vy-Shane Sin Fat wrote:
> On Mon, May 25, 2015 at 5:19 PM, Dhiruj Rambaran <dhiruj_at_shoponline.mu
> <mailto: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.
/ "And a smart business listens to its experts"..... I think this
says it all. It all depends if you're dealing with a smart business or not./
>
> 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 <mailto:nadim.attari_at_gmail.com>> wrote:
>>
>>
>> On 25 May 2015 at 11:21, Jochen Kirstätter
>> <mscc_at_kirstaetter.name <mailto: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 - 17:16:37 PST
This archive was generated by hypermail 2.3.0
: Mon May 25 2015 - 17:18:05 PST