Off-Topic > Off-Topic - Tiny Core Lounge

The direction of the development of computing

<< < (3/4) > >>

tinypoodle:
Nice way to put it.  :)

thane:
I write custom application software for a living. I've often found myself having to develop overly-complicated, potentially buggy applications because that was the only way to give the users the features they wanted.

But let's face it, ultimately software is for the people who use it. They don't care about technical things like maintainability, only that the application does what they want it to.

Jakob Bysewski:

--- Quote from: thane on January 01, 2011, 01:41:36 AM ---[...] having to develop overly-complicated, potentially buggy applications because [...] the users
[...] ultimately software is for the people who use it. They don't care about technical things [...]

--- End quote ---

I agree with you 100% that software is for it's users. I'm a software developer for a living too, but I have sworn to myself that I'll never again develop bad software because a customer want's me to. Software development is a very sophisticated art form and our customers have to respect that. I think they often want the "hit and run" approach because they made bad experiences with software developers making wrong promises or just don't want to think about technology.

Things like maintainability or well tested software should not be sacrificed for money - because in the end the customer will spit that back on us. I've had many cases where the customer wanted A and insisted it to be the most minimalstic, hackish version possible; but I knew that after having feature A---- for a week the customer would demand the "full version" - A+++.

Maybe I can provide a little - fake - example:
The customer want's to save data and have it searchable. At first only two persons will work with the software to be written, but if that's working well about 100 people will use it. If you can't agree upon doing a prototype first (wich is per definition to throw away and therefore allowed to be hackish!), would you
a) realize that program using serialization (java) / just write out the data into a text file (java, c/c++)
b) use a full fledged rdbms like MySQL
c) use a database, but make it in process, maybe H2 (for java) or sqlite (for c/c++) - this'll allow for easy upgrade later on if needed

Personally I'd aim at c) or even b) if I'm shure this will be needed soon. There are customers which will force you to a) if you make that thought available to them, because they think this will be the fastest, easiest and cheapest approach possible. But making such a design decision will hurt you if later on the customer needs more than the saved data in a text file (maybe to work in a distributed environment, or to have a quicker search, ...). If you have the technology available (here: rdbms) at very little cost it is - at least to me - careless to make bad software just because the customer insisted on wrong desing decisions that he'll regret very soon.
And I as a developer will regret such decisions too, because in secret my customer thinks of my work to be easily extensible when he needs this. This requirement is seldom to be spoken of loud, but in my experience it's there all the time and we have to make shure our customers value our extra work (wich costs them more money at first) to deliver a good product, which is on time, extensible, as bug free as possible and fullfilling the customers requirements to the fullest.

hiro:

--- Quote ---a) realize that program using serialization (java) / just write out the data into a text file (java, c/c++)
b) use a full fledged rdbms like MySQL
c) use a database, but make it in process, maybe H2 (for java) or sqlite (for c/c++) - this'll allow for easy upgrade later on if needed

--- End quote ---

I would choose d):
   determine the exact type and amount of data to be stored.

Jakob Bysewski:
 :D
Of course you are right - but this would be embedded in every step (how would one use a relational database without schema? - okay, okay I *have* seen people doing this, but you definitivly shouldn't). But also your d) does not answer the question *how* the data is stored (which is what my example is based on).

This also leads to another problem: The customer wants us to start coding at day 1 and not to gather requirements, because he thinks only the coding is productive work which gets him the product he wants. This is another fiction we have to work against, as a requirements enginieering may take up a good amount of the whole project time -> with testing considered the coding might be even the smallest fraction of a project.

Navigation

[0] Message Index

[#] Next page

[*] Previous page