|
I fraggin' Need it! Thanks 
|
|
|
|
|
I know thy ordeal...
and I like the farting part .
Mislim, dakle jeo sam.
|
|
|
|
|
If it needs to robust, just rewrite the thing! Quicker, Easier & Cheaper!! but no 'its there problem if it doesn't work'...nice idea if IMHO it stops working who gets call/yelled at the last person to have anything to do with it. 
|
|
|
|
|
glennPattonWork wrote: How can a piece of software that runs by luck be considered robust, you fart near it, it falls flat on its face!
A couple weeks ago I told a client I'm off the project. Along the lines of some article I read about contracting was the wisdom "Learn to say no even to money." The application, a crowdfunding website, is based on the open source project "catarse" (Ruby on Rails), and my fork of it (July 2013 or so) was what I was working with. Let's see:
The code is insane - it look like different people worked on it with different technology stacks
It's unstable - for example, emails are incorrectly sent to me for some projects, but not others, and I have no idea why.
It's overly complex - the use of events when straight forward code would have worked, layers of weird code between "do A" and "I'm doing A".
Ridiculous uses of technology - a one-off no-sql database being used to store a single value, once in the code, that is referenced somewhere else only once, but requires a completely separate daemon process to be running to support this critical path code.
Incomprehensible behavior - the whole behavior around what happens when a project expires is crazy, depending on a separate daemon task to update state and still remains a complete mystery as to how some states are transitioned.
It was too much!!! I couldn't separate out the hatred I started developing for the thing. But besides learning some actually cool stuff, I also learned something important about time and money. As long as there is some standard of efficiency to my time, then there's an equivalence to $'s. When the efficiency of the time utilization starts to nose dive, the "value" of the $'s being earned for that time diminishes rapidly. Why? Because I also want to be doing other things. And of course, because the $'s didn't increase for the same unit of time, the time-value per $ ratio started to get seriously out of whack. And that's what led me to saying "NO!"
Marc
|
|
|
|
|
It looking more and more like a band aid job...
|
|
|
|
|
glennPattonWork wrote: software that runs by luck
Still working on that VB project then?
It was broke, so I fixed it.
|
|
|
|
|
How did you guess, sleep is good, I sent the Exe that was desperately needed (it either works or they haven't realised it doesn't yet roll on the 24th) now I am fumbling with the VB that creates the ini file. XML, intelligent parsing No! flat text read in with the stream reader and pick it out with a substring (what can go wrong!) is the way to go... if I could get my hands on the original 9 year old that wrote this I would murder him!
[Off Topic] Your profile pic is a Les Paul (of some description) much of a player???
|
|
|
|
|
The fact that you're being asked to do that kind of duct tape work to ship something that full of bugs seems to me to be the real problem.
(Some might think the fact that you're agreeing to it would be another one.)
|
|
|
|
|
Quote: (Some might think the fact that you're agreeing to it would be another one.)
I didn't agree to do it, I wasn't even in the room. I got lumbered with the famous 'Glenn won't mind having a look at that' 
|
|
|
|
|
Hi, I usually reads a lot of documents specifying up time on applications but this was a new on for me. In an ongoing project they have specified that the application, when finished, should have at least 99.95% down time.
Makes me question why they are doing the project... 
|
|
|
|
|
Come on then, how will you guarantee no more 43 seconds runtime per day AND ensure all the other functionality is available?
speramus in juniperus
|
|
|
|
|
|
But it needs to be functionally complete...
speramus in juniperus
|
|
|
|
|
Language in the lounge!
|
|
|
|
|
Man! You are going to have to work hard on that...have you considered a splash screen that takes 23 hours, 59 minutes and 16 seconds to finish loading, then close your app down 44 seconds later?
But hard on the users though...they better learn to type real fast.
|
|
|
|
|
Could it be Task application? just synchronizing stuff for 44 secs every day?
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Oh, that project already made. they called it Vista...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: Oh, that project already made. they called it Vista...
know, it was called healthcare.gov
|
|
|
|
|
My Campervan is a 1976 VW Type 2 Super Viking
|
|
|
|
|
Marcus_2 wrote:
Hi, I usually reads a lot of documents specifying
up time on applications but this was a new on for me. In an ongoing project they
have specified that the application, when finished, should have at least 99.95%
down time. Makes me question why they are doing the project...
This requirement is common in financial industry, service web sites, etc. But you don't usually agree on software but on service (SLA). 99.95% availability means you can be down 1.5 days per year. That's a lot of hours. Imagine Facebook doing that ( or Apollo 11  ). If your company took the assignment it means they are either pretty sure of their capabilities or ... 
|
|
|
|
|
99.95% availability does, yes.
He is talking about 99.95% down time!
|
|
|
|
|
OriginalGriff wrote: He is talking about 99.95% down time!
Got me there.  Lawyers.
|
|
|
|
|
Tomaž Štih wrote: Lawyers.
Mind your language sir! A chap could take offence at being called one of those...
|
|
|
|
|
Sheep *lover*? Is that okay?
speramus in juniperus
|
|
|
|
|
Better than "lawyer" *ack!* *spit!*
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
