Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Sadek Drobi on Jul 25, 2007 12:00 PM
A new certification for software developers should not be about OOP, metaprogramming, macros, design patterns or any in depth knowledge of programming languages. Reginald Braithwaite believes that only one subject must be on the examination list: testing and quality control.Braithwaite stresses that this is not a debate on "whether to have separate testers or whether programmers should test themselves." He simply asserts that, judging from his experience, safety is of crucial importance for software development in commercial environment. Hence, developers' ability to ensure that software does what it is expected to do should be the prerequisite to any software development job:
My point here is that it's tough to call yourself a "professional software developer" if you aren't intimately familiar with the processes by which we evaluate the result of your work.
Imagine walking up to a Structural Engineer and talking about stress-testing materials. Wouldn't you be worried if they shrugged and said, "that's testing, I just design stuff"?
Certification is not meant to impose technology choices to businesses. It is not even meant to impose any kind of standards in term of software solidity. Managers can decide to ship software full of bugs, provided they are aware of that fact.
Such approach to certification is viewed as simplistic by Peter Harkins who argues that there is more to software development then safety. Using the restaurant business analogy, Harkins stresses that he certainly doesn't want to be poisoned while eating out, but he also wants "fine food, not just fast food." Braithwaite retorts that one may dislike Mc Donald's, but this is not a reason "to legislate them out of business." Having upper standards for software is good but one should not force it on others.
For Kyle Lahnakoski, certification is meant to provide information that is otherwise missing on labour market. If focused on safety, it may result in important losses for the company if the developer turns out to be "safe" but not "efficient". Chris, however, considers safety oriented certification as a good baseline criterion for hiring employees:
On top of this - and perhaps this is obvious and thus redundant - would then come the consideration as to whether or not someone can actually write code (cook), write good code (cook well), loves writing code, works well in a team, fits with the company, and the such (cooks well enough to work in an n-star restaurant).
This goes along with Braithwaite belief that whether a developer is employable is something marketplace can decide, based on technical skills and productivity of this developer. Certification is not the only requirement for employment, exactly as Chef's papers do not guarantee getting hired by a restaurant:
Do you think a restaurant would hire anybody with their Chef's Papers? Well, some might, but some would want to know who you've worked with, some would demand that you cook them a meal. And so it is with certification. I suggest such a thing be considered necessary but not sufficient.
Safety is the prerequisite; for the rest markets will decide.
Effective Management of Static Analysis Vulnerabilities and Defects
The Role of Open Source in Data Integration
Velociti Partners Customer Survey
I think that the same certification should apply to the companies and their budgetting management. In my experience, the only developers avoiding testing were those that never got a budget for this. And even if due to this their life was/is harder there is almost nothing they can do :-(. ./alex -- .w( the_mindstorm )p. ________________________ Alexandru Popescu Senior Software Eng. InfoQ TechLead&CoFounder
I think that the same certification should apply to the companies and their budgetting management. In my experience, the only developers avoiding testing were those that never got a budget for this. And even if due to this their life was/is harder there is almost nothing they can do :-(.
./alex
I guess it depends on the company. Some companies target this market of buggy cheap software. Personally I would quit fast after I am hired in such a company. For some other companies, quality really matters, and that’s where you can fight for having a budget for quality. Most of my missions fall in one of these two company cases. Surely there might be others, where quality matters, but management is not aware of methods that assure it. In that case, well they will once realize it. Hope it won’t be too late for them :)
Sadek
Looks like I wasn't able to pass my message thru :-).
My point is that it would be nice if you would be able to know upfront if a company is using correct processing before joining it and having to fight to establish these processes (or quitting).
Also, by reading your message I am getting the impression that you've been in the position where people/developers were afraid of testing. In my experience I haven't seen this, but rather situations were people were not able to start testing due to some real reasons (lack of budget, lack of experience, wrong solutions, etc.).
Some companies target this market of buggy cheap software.
This may be shocking but:
- the lack of testing budget doesn't mean the software is cheap
- (believe it or not :-) ), I've seen successful projects with very small QA cycles.
However, I am not saying that this is happening everywhere.
bests,
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
>>- (believe it or not :-) ), I've seen successful projects with very small QA cycles. I believe it. Unless the software is inherently complex, I think ensuring the business goals are being achieved is much more important than having a robust testing and QA process. I like to use TDD in an Agile framework, mostly bits of Scrum and EVO. But in my experience, the largest "bugs" are not due to bad code; they are due to developers working against incorrect, insufficient, or obsolete requirements. If the QA cycles don't include some type of business stakeholder review, you're not really assuring the important quality metric, I think.
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
4 comments
Watch Thread Reply