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 Wednesday, August 20, 2014 8:17 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 5:59 PM
Points: 31,082, Visits: 15,529
Comments posted to this topic are about the item Bronze Age Development






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1605646
Posted Wednesday, August 20, 2014 11:11 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, August 21, 2014 6:18 AM
Points: 2, Visits: 21
I think the term bronze age development really does sum up writing t-SQL, there are some tools which are starting to emerge and get better but the tooling is a long way behind that of c# or other languages.

A big issue for me is debugging, with SQL server you can step into a stored procedure but can't see the contents of a table, want to check the results of a cte?? Add an additional select and run the cte twice in your procedure!

Post #1605658
Posted Thursday, August 21, 2014 12:36 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: 2 days ago @ 12:27 AM
Points: 50, Visits: 349
"Never test! What's the point, the client will tell us what they really want and then we will look great as a company when we fix it and deliver it."

Paraphrased from various vain-glory managers/directors of software houses that I have worked from over the years. Try implementing ITIL or any good practice in those environments is an uphill struggle to say the least.

Post #1605673
Posted Thursday, August 21, 2014 2:24 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:41 PM
Points: 5,471, Visits: 3,258
I have been an advocate of developer unit testing for what seems like forever as I had my eyes opened up to the value of it at college both through empirical studies and experience writing trivial applications. When automated unit testing came along with TDD (or were the early tools a bit before?) into the Windows development world I eagerly embraced and encouraged their use. It makes development take a bit longer but you remain focussed on only developing what you need. The amount of time in integration, component and acceptance testing seems to be reduced. Unfortunately, I have not been in a position to measure the results but I have not seen the same sort of problems that have continually delayed releases of most projects that didn't do the testing.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1605702
Posted Thursday, August 21, 2014 3:40 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, August 21, 2014 9:43 AM
Points: 4, Visits: 7
I will suggest that the ratio of testing time/effort over development time/effort should be getting larger over time.

I'll assert that analysis and requirements definition is a process of understanding what is really needed and stating that in a clear and understandable manner. Similarly, Testing is a process of making sure that what you have is fit for purpose. Both of these are likely to take a significant time for any system that is non-trivial. The size of these is controlled by the problem-space of the software. Development is different. The use of Open Source code, reuse of components and modern development tools should mean that the development needed to solve a particular problem should be reducing over time.

On that basis I we could suggest that over time a ratio of test time over development time could be used as a performance indicator of the maturity of the development approach. The bigger the better.
Post #1605722
Posted Thursday, August 21, 2014 4:25 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:41 PM
Points: 5,471, Visits: 3,258
david.howard (8/21/2014)
I will suggest that the ratio of testing time/effort over development time/effort should be getting larger over time.

I'll assert that analysis and requirements definition is a process of understanding what is really needed and stating that in a clear and understandable manner. Similarly, Testing is a process of making sure that what you have is fit for purpose. Both of these are likely to take a significant time for any system that is non-trivial. The size of these is controlled by the problem-space of the software. Development is different. The use of Open Source code, reuse of components and modern development tools should mean that the development needed to solve a particular problem should be reducing over time.

On that basis I we could suggest that over time a ratio of test time over development time could be used as a performance indicator of the maturity of the development approach. The bigger the better.


I agree with almost all that you said except that, from what I have seen, most improvements in development tools and Open Source libraries have been targeting new technical complexities not ones that have existed long term. There are many examples of JavaScript libraries that are there to simplify development of a modern UX which just didn't exist before. There are some BI JavaScript libraries too, to further the examples, that provide facilities that there just wasn't a demand for ten years ago. Additionally, I don't see a vast improvement in the tooling that would speed up development except Continuous Integration Servers and Unit Testing tools. Better support for x64 (which didn't exist before) and multi-threading debugging are advances but mainly to cover only what no one or a minority were doing more than a few years ago. Also, I am not seeing companies better able to leverage existing systems or components than occurred 20 years ago.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1605732
Posted Thursday, August 21, 2014 6:02 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, August 21, 2014 9:43 AM
Points: 4, Visits: 7
A simple counter example would be that using Open Source software I could put together a Customer Relationship management solution with little to no Development. The time taken to understand the actual need and to test that the solution works correctly and answers that need completely would still be fairly significant. There are similar examples in many areas.

I'd agree that much of the development tool advancement has gone into doing things that wouldn't be done before. There are, however, cases of reuse and tool improvements that improve productivity for deliver systems that could have been produced previously as well.
Post #1605770
Posted Thursday, August 21, 2014 6:19 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, September 26, 2014 7:35 AM
Points: 9, Visits: 21
Lets just say that the developer may have said no bugs, but his users didn't. (Unless they "tested" using production data.) The other thing this tells me is that the developer made some forms that look just like the paper he was replacing.

Good software does more than the typical user can grasp. It does it more efficiently then they will come up with on their own. Most UIs put way too much on the screen. And users typically want more than is there. And a developer can't move them to the next level without mistakes. Because the developer can't completely understand the problem.

Quite simply software is, has always been, and will always be an iterative process. Now if you have people who will start using the software bits (in production where they really understand), then you can discover and tweak during testing. But the user can't replicate the process without working in production. Nor can a few users actually predict what that one user (everyone has one of those users) will somehow do in spite of your best efforts to make them do what you want. That user will even want to do that very thing, but somehow that user ALWAYS finds a way to muck it up. And that IS a bug.

One thing that would help is an awareness of what is "good enough." Combine that with getting others to understand what is good enough. I was lucky to work on a project for a manager who wanted good enough. And he (and the users) were very happy with the results (knowing about the bugs). We quickly resolved the worst of them and slowly took out most the rest.
Post #1605771
Posted Thursday, August 21, 2014 6:24 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:53 PM
Points: 2,581, Visits: 3,883
I have been a developer for a long time and have always spent much more time testing than writing code. I think double would be pretty close. It got me in trouble with one employer who said that testing was for programmers who didn’t know what they were doing to begin with. The only lesson I learned from that was that testing was for those who DO know what they are doing. That shop spent more time fixing their untested code than moving on to new projects.

Long before agile was a buzzword I used some of its principles. I like to use the term “iterative development”. Iterations involve the customer and other stakeholders. An iteration lasts about two weeks and involves testing. Each iteration results in cleaner code until the user says we’re finished. I don’t know if the iterative process shortens the development lifecycle. What I do know is that it results in happy customers because they get what they want and they know it works properly. There is very little fixing to do afterwards. Another thing that’s good about the iterative process is that it keeps me on track. I tend to procrastinate and having short term deadlines helps keep me focused.

Tom
Post #1605772
Posted Thursday, August 21, 2014 6:25 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:41 PM
Points: 5,471, Visits: 3,258
david.howard (8/21/2014)
A simple counter example would be that using Open Source software I could put together a Customer Relationship management solution with little to no Development. The time taken to understand the actual need and to test that the solution works correctly and answers that need completely would still be fairly significant. There are similar examples in many areas.


That is a very good example. You are perfectly correct. Particularly if you look at some systems more generically.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1605773
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse