Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234

Bronze Age Development Expand / Collapse
Author
Message
Posted Thursday, August 21, 2014 10:15 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 7:33 AM
Points: 1,792, Visits: 5,042
Perahps most IT development shops in 2014 are in the "Early Industrial Age", where is goal is leveraging tools to crank out a lot of "good enough" code but there is not enough emphasis on process and quality.
Post #1605914
Posted Thursday, August 21, 2014 11:48 AM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 8:21 AM
Points: 4,610, Visits: 4,064
Eric M Russell (8/21/2014)
If sufficient functional requirements are not provided upfront, then all these "fixes" in production are really just change requests and phase I, II, ~ deployments. A solution that has been in production for months shouldn't be considered "broken" just because someone wakes up one morning and decides it should be working in a different way.

OMG!!! Allow me to beat the proverbial drum and give this a +1000. I wish people would understand this fundamental concept, but it's a hard sell when they believe that their every whim should already be accounted for by software that they needed finished before they even asked for it.



Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions
Post #1605947
Posted Thursday, August 21, 2014 11:54 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 1:21 PM
Points: 229, Visits: 650
Ed Wagner (8/21/2014)
Eric M Russell (8/21/2014)
If sufficient functional requirements are not provided upfront, then all these "fixes" in production are really just change requests and phase I, II, ~ deployments. A solution that has been in production for months shouldn't be considered "broken" just because someone wakes up one morning and decides it should be working in a different way.

OMG!!! Allow me to beat the proverbial drum and give this a +1000. I wish people would understand this fundamental concept, but it's a hard sell when they believe that their every whim should already be accounted for by software that they needed finished before they even asked for it.


Second that!
Post #1605949
Posted Thursday, August 21, 2014 12:52 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, December 12, 2014 9:23 AM
Points: 206, Visits: 402
In a database world, a long, long time ago, Sybase was king. Then, a version was released that was so bad, it came close to tanking the company. I'm pretty sure in hindsight they wished they did a bit more testing. (and, I sure quite a few of you remember when you needed to buy Sybase books to better understand the early releases of SQL Server).

So, yes, do please test. When I was chief software architect of a start-up years ago, we setup a continuous integration process. code check-ins could invoke a full rebuild, along with a fully automated set of unit tests and end-to-end tests. If you can get a continuous integration process setup, do it. A bit of a hassle at first, but it makes it easier to test.


The more you are prepared, the less you need it.
Post #1605968
Posted Friday, August 22, 2014 1:35 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:22 AM
Points: 2,923, Visits: 1,873
I've been watching a series following the training of the Royal Marines. One of the corporals made the comment that their standards are very high for a reason. They will do everything possible to help the recruits meet those standards but those standards will not be lowered under any circumstances.
They know they are being tough but do be anything else does the recruits no favours. If the bar is lowered then a Royal Marine would be a danger to themselves and, more importantly, a danger to their comrades. Those high standards are why the Royal Marines are an elite group and highly respected.

I've often wished this attitude prevailed in software development. Set high, uncompromising standards to which IT staff have to deliver. Relaxing those standards will have a knock on effect that will be detrimental to the deliverable and return to bite them and their colleagues in the bum.

You may not think this is practical but my personal experience is that the time spent bug-fixing after deployment is far greater than the time spent being a stickler for quality. More and more time is spent coding around buggy and tech debt riddled releases on each subsequent releases.

In my career I can think of only a couple of occasions when the deadline for delivery was truly important enough that it had to be released come what may. The rest have been arbitrary deadlines to allow a manager to claim a bonus. Said managers would accept almost anything in order to get their bonus knowing that the next quarters objectives would have absolutely nothing to do with the software they had just signed off. Someone else would become responsible for the freshly delivered turd and they would get away scot free.

Test your software as if a bug found after deployment would be a proven slur on your bedroom prowess.

Stop complaining and (as the Marines say) "man up princess".


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1606486
Posted Friday, August 22, 2014 4:45 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:43 PM
Points: 2,494, Visits: 1,581
Gary Varga (8/21/2014)
Also, I am not seeing companies better able to leverage existing systems or components than occurred 20 years ago.


Gaz, respectfully, your historical perspective might be too short. I do see companies much better able to leverage existing systems and components today compared with 40 years ago. In the longer wave in the cycle, the change is more noticeable.

M.




Not all gray hairs are Dinosaurs!
Post #1606533
Posted Saturday, August 23, 2014 7:33 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:14 AM
Points: 5,816, Visits: 3,736
Miles Neale (8/22/2014)
Gary Varga (8/21/2014)
Also, I am not seeing companies better able to leverage existing systems or components than occurred 20 years ago.


Gaz, respectfully, your historical perspective might be too short. I do see companies much better able to leverage existing systems and components today compared with 40 years ago. In the longer wave in the cycle, the change is more noticeable.

M.


Miles, I totally agree. I do feel that 15 years of stagnation is a long time in this industry.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1606643
Posted Monday, August 25, 2014 9:49 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:43 PM
Points: 2,494, Visits: 1,581
Gary Varga (8/23/2014)
Miles Neale (8/22/2014)
Gary Varga (8/21/2014)
Also, I am not seeing companies better able to leverage existing systems or components than occurred 20 years ago.


Gaz, respectfully, your historical perspective might be too short. I do see companies much better able to leverage existing systems and components today compared with 40 years ago. In the longer wave in the cycle, the change is more noticeable.

M.


Miles, I totally agree. I do feel that 15 years of stagnation is a long time in this industry.


Agreed, 15 years is far too long! Years ago we use to use the slogan "Change or die” We were not allowed because of the creative pushing us to slow. We had to move forward or be crushed by the innovation that was almost daily.


Not all gray hairs are Dinosaurs!
Post #1607119
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse