Please wait...
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.
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."
Building in the same language and framework is great. Until you come across
something written in Visual Basic and Classic ASP.
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.
Tue Jun 13 2017 10:03:49 AM EDT from kc5tja @ UncensoredMore succinctly: beware the rockstar coder. They're dangerous, and have a propensity to build products to sell companies, not to satisfy customer demand.
<laughs>
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.
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.
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.
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.
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.
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.
*Cough*. LH: fixed pricing, hard dates, all requirements actually implemented as requested... choose any two!
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"!
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.
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.
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.
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'?
