Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 23 24 25 26 [27] 28 29 30 31 ... Last
[#] Tue Jun 13 2017 17:05:24 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Their architectural approach is "build a big huge webservice module
deployed to a separate machine" for a small bugfix that should have
involved writing a new .class or two and wiring them into the existing

execution flow.

This is known in the buzzword-compliant world as "service oriented architecture" (SOA)

And the deployment people just *love* being asked to stand up two dozen services where one would have sufficed.

[#] Tue Jun 13 2017 17:14:11 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Ford, however, simply calls this, "Progress."

(Mockingly, for those who don't know him).

[#] Wed Jun 14 2017 02:40:08 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Or as I've always preferred to say it: "We've been automating the same tasks for 50 years, and we keep getting less and less efficient at it."

[#] Wed Jun 14 2017 19:13:27 UTC from Ragnar Danneskjold

[Reply] [ReplyQuoted] [Headers] [Print]

Building in the same language and framework is great. Until you come across something written in Visual Basic and Classic ASP.

[#] Wed Jun 14 2017 20:21:16 UTC from bennabiy

[Reply] [ReplyQuoted] [Headers] [Print]

Sometimes the building process takes burning down first....



[#] Wed Jun 14 2017 20:27:30 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Building in the same language and framework is great. Until you come

across something written in Visual Basic and Classic ASP.

I don't think I would want to work with anyone who's made those kind of stupid design decisions at any point in the past.

[#] Wed Jun 14 2017 20:41:13 UTC from Ragnar Danneskjold

[Reply] [ReplyQuoted] [Headers] [Print]

Can't blame managment when they don't have anyone to tell them any better....

[#] Wed Jun 14 2017 21:57:28 UTC from Ladyhawke

[Reply] [ReplyQuoted] [Headers] [Print]

 

Tue Jun 13 2017 10:03:49 AM EDT from kc5tja @ Uncensored
More succinctly: beware the rockstar coder. They're dangerous, and have a propensity to build products to sell companies, not to satisfy customer demand.

<laughs>



[#] Thu Jun 15 2017 11:18:23 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

2017-06-14 16:41 from Ragnar Danneskjold @uncnsrd
Can't blame managment when they don't have anyone to tell them any
better....


That was my experience at my previous company.

Web pages written in Classic ASP, then mixed with modern ASP in ways that made it impossible to get the two to talk properly with each other.

Code not just for web pages written in VB (not .NET VB, either) such that I had to write stuff in C++ to work with the VB stuff just to kinda-sorta get things to work properly.

All this because the CEO wrote the original code, and we never had time to refactor to something... better.

[#] Fri Jun 16 2017 17:07:42 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

like 4 hawks in surround sound.  It's often hard just to get clients
to pay for the most basic of things they need to avoid breach, much
less "nice to haves"....forget about extra bells and whistles.

@LH, the problem may be that we use these guys more as an extended part of our core staff, as opposed to a group to which we contract out a discrete set of larger projects with defined requirements. And we are agile. And the guy here who manages the worst offenders is a bit weak at policing them, so they get away with a lot.

That happens when there's a 6h time difference, too - they tend to operate independently during those non-overlapping hours, and what they come back with is not always what was expected.

But all that said I really do have a problem with their judgment. They want to work on greenfield projects all the time. Even when it's brownfield, they try to find ways to turn it into a larger-scope greenfield thing. No bueno.

Not naming names because I have no desire to escalate a semi-anonymous rant into a public shaming; that would be unprofessional.

[#] Sat Jun 17 2017 00:07:30 UTC from Ladyhawke

[Reply] [ReplyQuoted] [Headers] [Print]

I can see that, LS.  And all of that would be exacerbated in an Agile only shop, too, since Agile depends on "radical accountability", which is not something that all cultures share.  

We use a multi-method approach in our group.  I'd like to inject more from the Agile framework into the method than we have.  Unfortunately, we've found it just doesn't function well enough in a product implementation environment that requires fixed pricing and hard dates to use more than a few principles.



[#] Sat Jun 17 2017 03:54:32 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

That's true; agile was explicitly not designed to support fixed schedules.
It's goal was to enhance improved (but not perfect) scheduling based on measured team velocity figures. If fixed schedules are preferred, I think alternative approaches, such as Spiral or V-model, are preferred. We used a mixture of V-model and scrum at Plum District, and it worked *awesomely*. Best coding experience I've ever had in my career.

[#] Mon Jun 19 2017 11:15:40 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


We can't rely upon fixed schedules here... we're asked to wear so many hats, and we lack the employees to properly do anything, if we had to stick to strict schedules, we'd have the shittiest releases imaginable.

This is one of the weirdest experiences... a large company with an almost small company feel in ways. We have some of the advantages of the small company (flexibility, dynamic environment, constantly on-the-move, etc) and some of the advantages of a large company (stable paycheck, some degree of infrastructure to solve problems, etc), yet one of the serious disadvantages of a large corporation that involves struggling to meet expectations, and shitty management.

[#] Wed Jun 21 2017 22:28:56 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


*Cough*. LH: fixed pricing, hard dates, all requirements actually implemented as requested... choose any two!

[#] Thu Jun 22 2017 10:07:00 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Pretty much.

[#] Fri Jun 23 2017 13:42:00 UTC from Ladyhawke

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Jun 21 2017 06:28:56 PM EDT from LoanShark @ Uncensored

*Cough*. LH: fixed pricing, hard dates, all requirements actually implemented as requested... choose any two!

Ha!  Precisely.  Now if only clients ever actually understood the word "constraint"!



[#] Mon Jul 10 2017 01:05:47 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

It's goal was to enhance improved (but not perfect) scheduling based

on measured team velocity figures. If fixed schedules are preferred, I


Protip: work really slowly during the initial measurement of team velocity.

[#] Tue Jul 11 2017 17:11:03 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

I have a copy of Watts Humphrey's book on PSP, and have even used some of its methods in my own projects (both personal and at work). I'm happy to report that they actually work. What sucks, though, is that they're horribly intrusive, and thus you rarely find yourself "in the flow."

I was able to plan out a project six months in advance with PSP, and shipped only a week late. Pretty awesome stuff, even accounting for interruptions.
That said, I won't be doing that again, at least until significant automation happens.

[#] Tue Jul 11 2017 17:38:44 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Heh... something amusing in rails:

[WARNING] The model name 'SeriesLabs' was recognized as a plural, using the singular 'SeriesLab' instead. Override with --force-plural or setup custom inflection rules for this noun before running the generator.

What is the singular for 'Series'?

Go to page: First ... 23 24 25 26 [27] 28 29 30 31 ... Last