|
Close but no cigar. Cigars however had a far greater effect, along with cigarettes on my teef.
veni bibi saltavi
|
|
|
|
|
Maybe the Gin kicked in?
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
I have been asked ( volunteering myself to be precise) to create a complete software framework to replace the existing software. Existing software "works" but has always been painful when Engineers had to use it. Too Buggy/unstable and way too complex architecture We have been cribbing about it and Management treated as low priority because we had enough day to day work.
This week , they informed me that "rework/upgrade" is still low priority but I (since I complained the lot or was louder) can start thinking about changing it and it may change to higher priority in future.
Good news : I have been given freedom to either upgrade/rework or start from scratch.
Bad news : I have to work on this when there some "free" time. and it has no "official" cost center
So based on this situation, does it make sense to start from scratch or apply Band-Aid to existing framework.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
If "free" time is your time outside of work, ie: unpaid production time, then you would be volunteering to rewrite a commercial grade application without compensation.
If it will be done during working hours and there is no "official" cost center, then where is your time charged to? If you are being paid, someone is absorbing the cost.
Years ago, I faced a similar situation: I decided it was a good opportunity to take the time to design before writing any code. The entire application was written in pseudo-code to check the flow of data and then I started to write the actual code. It took some time, but it was the better solution in the long term. And yes, I still had to band-aid the old system until the new one was available.
|
|
|
|
|
Tim Carmichael wrote: If "free" time is your time outside of work, ie: unpaid production time, then you would be volunteering to rewrite a commercial grade application without compensation.
If it will be done during working hours and there is no "official" cost center, then where is your time charged to? If you are being paid, someone is absorbing the cost.
Only monkeys work for peanuts 
Tim Carmichael wrote: It took some time, but it was the better solution in the long term. And yes, I still had to band-aid the old system until the new one was available.
It's always the same song, isn't it? It's the lowest thinkable priority, may not cost anything, should have some new features while we are at it and must probably get finished some time next week. All that, of course, while keeping the old junk alive until then.
I only miss one more important ingredient: Where are the guys who protest against their greatest work of art being kicked into the bucket?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Tim Carmichael wrote: If it will be done during working hours and there is no "official" cost center, then where is your time charged to? If you are being paid, someone is absorbing the cost.
No official cost center means , I cannot take much of the time of the other guys/department. I am covered by the umbrella cost center which I can use it when I am not in any project. The only check is that it cannot be more than 25 hours in a month for me.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
Tim Carmichael wrote: then you would be volunteering to rewrite a commercial grade application without compensation.
Glad someone mentioned this. 
|
|
|
|
|
Piecemeal refactor might be your best bet, unless it's so badly designed that it's not possible.
Alternatively you could follow the BDD route, develop tests to model what the expected workflows look like, then begin to patch from there.
There are other variables, of course. Is it compliant with the current version runtime? Is it tightly coupled at the data layer? Is it maintainable? Check some of these blocks to help decide whether to rewrite or patch.
|
|
|
|
|
Nathan Minier wrote: Piecemeal refactor might be your best bet, unless it's so badly designed that it's not possible.
Have you ever been so lucky?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Usually, yes; if it can be broken down into logical pieces (i.e. not procedural).
I should have added a caveat: if it's WebForms, kill it with fire.
|
|
|
|
|
Then you are really lucky. I quit my last job because of a large, unstructured and completely unducumented mess which had accumulated in about 20 years. Any work on this thing had to be finished within a few hours, had to be state of the art and we were also not entitled to at least a mildly informative assignment. A single vague sentence had to be sufficient.
And yes, yesterday I heard from my former coworkers that their bossette also thinks that I am obviously incompetent because I did not want to keep up with such working conditions. That's fine for me. Being called incompetent in a place where incompetence has been elevated to a form of art is actually a praise.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I'm afraid that what you're calling lucky is more akin to stubbornness.
That sounds more like a managerial issue than a (fundamental) code issue, though.
|
|
|
|
|
CDP1802 wrote: Any work on this thing had to be finished within a few hours, had to be state of the art and we were also not entitled to at least a mildly informative assignment. A single vague sentence had to be sufficient.
Isn't that the way things should be? 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Yes, under normal conditions. Even then I would prefer at least some information in an error report. Something that answers stupid questions like 'Who did what in which application/form, what values did he enter, what buttons did he click and what exactly were the results?'.
Edit: Not to forget silly questions like 'What the *** are we doing here, how does the process work or what are the requirements?'
I think they invented a new method of software development. Forget agile or the old waterfall model. This was the anthill model. For 20 years uninformed ants had been expanding and repairing this particular anthill. Ants need not to be told what to do or how to do it and never waste a thought about architecture or other unprofitable stuff.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I see, that you so pissed-off at that company, that you can't even see a joke icon...
Take it easy and bless your good fortune, you are not there anymore
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
You are half right. This company is a sinking ship. It's actually a pleasure to hear that they finally noticed something after getting wet, but it also makes me a little angry when I hear what's happening to those who did not reach the lifeboats in time.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
As it based on your free time (do you have any? if so you may want to visit the QA )...
I would spend a bit of time to see if the old code can be reused in a modular way - I mean to split the wrong from good and use the good while dumping and replacing the wrong...
If the reusable part is far too small to spend time on the splitting process, than go for a total rewrite (but for the first version do not introduce new features, but only the old ones with necessary fixes)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
First thing I would do is print out all the source code and cover the floor of a room with the source code. Spend a good couple of days understanding the source code annotating it with markers and highlighters.
Then you might be in a better place to decide on whether to rewrite from scratch or refactor.
One very good piece of advice I read is - the quirky code that appears to be buggy was written the way it was written for very specific reasons, if you go rewriting it there is a chance that you might break a lot more than that one method.
The advantage of refactoring code is that you can gradually fix the code - so while it may be buggy in places you can be fairly certain that what you are doing is improving the code and 'correctness' of the code.
There is no reason why in your refactoring that you cannot in effect be writing a new framework at the same time, so slowly the code morphs into a better framework - it's not necessarily a start from scratch or fix the buggy code choice.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It's a rare opportunity to be able to start from scratch -- you can fully own, not just the design, the architecture, and the code, but usually the other bits too that make for a great project, the documentation, the testing process, etc.
The "free time" thing though bothers me -- it sounds like a skunk works project. Management needs to see the sense (or in their terms, the cost benefit) of properly sanctioning the effort. If not, honestly, I wouldn't do it. You'll find it frustrating to work on it in a halfass way, and you and the project will suffer for it.
Marc
|
|
|
|
|
Marc Clifton wrote: The "free time" thing though bothers me -- it sounds like a skunk works project
I have a umbrella cost center which I fill my time against in between project. It cannot be more than 25 hours in a month.
My manager has suggested that I spend some time to decide the approach and then he will back me up to make this an official project where other departments can work on it too.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
Spend a week or two as if you would never consider throwing the old code away.
After that, you can make what management likes to clal an "informed decision": you should have learned to read and navigate the code base, gotten over the "uh, those member function names are all lowercase, the code is total crap", and learned a few of the complexities / details that you would have missed from the spotty specification.
|
|
|
|
|
If you can wrap the old system in some dirty API's and then build the new in the preferred architecture. If you get this right, then you can switch to the 'new' architecture at little or no cost. The first cut would simply be the old gubbins wrapped in the new container. Then as new work comes along it can be written as 'native' to the container.
veni bibi saltavi
|
|
|
|
|
I would probably try to fix and glaring issues with the current software and at least get it stable first with an eye to eventually rework to a simpler model.
"Go forth into the source" - Neal Morse
|
|
|
|
|
You've got two monitors, haven't you?
Work on your new solution in one, but keep the old "dissolution" open in the other, so you can look up all the little things that were added with duct tape, over the years (because they're probably more important than the core).
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
So, after discovering few of the racist tweets from Microsoft's twitter bot TAY, I decided to check out its website[^]. It is such an eye burning design that after looking at the home page for a couple of minutes everything around me seemed to be changing its color 
I mean, look at the color combination and don't forget to re-size your browser window. The Microsoft logo will overlap with social buttons.
Now I am wondering what was badly designed? website or the bot? I think still latter beats the former. Were the people at Microsoft in a hurry? Is the end of the world around the corner? 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
