Best Software development methodology for driver development

Hi all,

I would like to know your view on selecting a software development
methodology for windows driver development.
What is the best Software development methodology for driver development and
why?

Thank you.


Prageeth Madhushanka
Mobile: 0777935559
College: APIIT 2010
High School: R.C.C.W 06

What makes you think driver development is that special? Std best practices for creating software will do you just fine

d

tiny phone keyboard + fat thumbs = you do the muth


From: prageeth madhushanka
Sent: Sunday, January 17, 2010 8:53 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Best Software development methodology for driver development

Hi all,

I would like to know your view on selecting a software development methodology for windows driver development.
What is the best Software development methodology for driver development and why?

Thank you.


Prageeth Madhushanka
Mobile: 0777935559
College: APIIT 2010
High School: R.C.C.W 06

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Prageeth Madhushanka wrote:

I would like to know your view on selecting a software
development methodology for windows driver development.
What is the best Software development methodology for
driver development and why?

I would say outsourcing because of how much cost can be saved.


What makes you think driver development is that special?

Ouch!

I don’t think one can so easily brush off the important distinction of
software that causes an annoying message box on your screen when it blows up
from one that causes a bugcheck - especially when asked by someone whom is
starting from the point of (admitted) minimal experience in NT kernel
development.

Perhaps if you qualified what you (Doron) understand to be the not so
special development methodology, of say, the WDF framework team and how it
achieved the result it did, it might be more illustrative of just exactly
what ‘best practices’ are (or should be) in kernel development.

I am going to go out on a limb and imply that the framework team spent a
whole lot more time in requirements analysis, architecture, design, unit
test design, review, and all of the other things that ensure quality is
*designed in* than might be understood by the statement above!

Cheers,
Dave Cattley

We did exactly that. But how is that different than creating a line of business app, a web server backend, or anything else that requires good design, understanding of the environment and contraints you are working in, and good engineering? Thet are all the same best practices. Writing a driver is not the same as writing a tray notification app for sure, but any “serious” or real software project share the same phases/attributes of the dev lifecycle

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: David R. Cattley
Sent: Sunday, January 17, 2010 9:27 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Best Software development methodology for driver development


What makes you think driver development is that special?


Ouch!

I don’t think one can so easily brush off the important distinction of
software that causes an annoying message box on your screen when it blows up
from one that causes a bugcheck - especially when asked by someone whom is
starting from the point of (admitted) minimal experience in NT kernel
development.

Perhaps if you qualified what you (Doron) understand to be the not so
special development methodology, of say, the WDF framework team and how it
achieved the result it did, it might be more illustrative of just exactly
what ‘best practices’ are (or should be) in kernel development.

I am going to go out on a limb and imply that the framework team spent a
whole lot more time in requirements analysis, architecture, design, unit
test design, review, and all of the other things that ensure quality is
designed in than might be understood by the statement above!

Cheers,
Dave Cattley


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

My principal point was that (and sorry, I know you are constrained by input
device) the one line answer left unsaid all of the key elements you just
painstakingly typed on the phone. Leaving those to be filled in by
questioner assumes that the questioner has your understanding of what a best
practice is.

In my experience, and especially with new entrants to the kernel development
world, it is better to list them out to re-emphasize the importance of each
in the quality of the result.

Regards,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, January 17, 2010 12:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Best Software development methodology for driver
development

We did exactly that. But how is that different than creating a line of
business app, a web server backend, or anything else that requires good
design, understanding of the environment and contraints you are working in,
and good engineering? Thet are all the same best practices. Writing a driver
is not the same as writing a tray notification app for sure, but any
“serious” or real software project share the same phases/attributes of the
dev lifecycle

d

tiny phone keyboard + fat thumbs = you do the muth

>I would like to know your view on selecting a software development methodology

All off-the-book methodologies are bullshit.

The only valuable books on this are the ones written about the real teams who have success in at least 1 - or better more - products. Microsoft is a sample.

But note that the practices from successful big company can be unsuitable for successful small company :slight_smile:


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> In my experience, and especially with new entrants to the kernel development

world, it is better to list them out to re-emphasize the importance of each
in the quality of the result.

The bug cost (in terms of “hours to fix”) is very high in the driver. Much higher then in any UI/web project.

The requirements on platform knowledge are huge.

But! the task formulation is usually very simple.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

On 1/17/2010 6:03 PM, Doron Holan wrote:

What makes you think driver development is that special?

Our server administrators.

Can’t we follow any agile methodology, for windows driver development ?
I found methodology called Test Driven Development, but it does not cover
planning,designing and documenting.It only covers development and testing.
Although I agree , that driver development involves with lot of coding and
debugging , I also need to find out good methodology which can cover all the
above phases.

Aren’t you people follow any methodology for your industrial driver
development project?

On Mon, Jan 18, 2010 at 1:55 PM, Hagen Patzke wrote:

> On 1/17/2010 6:03 PM, Doron Holan wrote:
> > What makes you think driver development is that special?
>
> Our server administrators.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

You can do whatever you want. For what it is worth, Testing never made
anything better. It only serves to prove you didn?t make it as good as you
planned. So if ?Test Driven Development? is a fancy term for avoiding
requirements analysis, architecture, detailed design, unit test design,
coding, and verification because they are somehow deem ?too heavy weight?
for the project, please just be sure to put some sort of label on the
resulting driver so the rest of us know when we see it to expect it to
bugcheck on every edge condition that ?testing? did not anticipate but that
occurs with alarming frequency in the real world.

Good luck storming the castle!

Dave Cattley

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of prageeth madhushanka
Sent: Thursday, January 21, 2010 10:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Best Software development methodology for driver
development

Can’t we follow any agile methodology, for windows driver development ?

I found methodology called Test Driven Development, but it does not cover
planning,designing and documenting.It only covers development and testing.
Although I agree , that driver development involves with lot of coding and
debugging , I also need to find out good methodology which can cover all the
above phases.

Aren’t you people follow any methodology for your industrial driver
development project?

On Mon, Jan 18, 2010 at 1:55 PM, Hagen Patzke wrote:

On 1/17/2010 6:03 PM, Doron Holan wrote:
> What makes you think driver development is that special?

Our server administrators.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

>

You can do whatever you want. For what it is worth, Testing never
made
anything better. It only serves to prove you didn’t make it as good
as you
planned.

Or that you planned it perfectly but made a mistake in the execution of
your plan. Mistakes happen, and that is why we test.

Testing should be a part of any development cycle, but if your
development plan is “no plan, just test it until it works” then yes,
you’re doing it wrong :slight_smile:

As Donald Knuth once said “Beware of bugs in the above code; I have only
proved it correct, not tried it.”.

James

>>> I found methodology called Test Driven Development, but it does not
cover planning,designing and documenting.It only covers development and
testing.

Are you sure about that ?

-saurako

On Thu, Jan 21, 2010 at 11:01 PM, David R. Cattley wrote:

> You can do whatever you want. For what it is worth, Testing never made
> anything better. It only serves to prove you didn?t make it as good as you
> planned. So if ?Test Driven Development? is a fancy term for avoiding
> requirements analysis, architecture, detailed design, unit test design,
> coding, and verification because they are somehow deem ?too heavy weight?
> for the project, please just be sure to put some sort of label on the
> resulting driver so the rest of us know when we see it to expect it to
> bugcheck on every edge condition that ?testing? did not anticipate but that
> occurs with alarming frequency in the real world.
>
>
>
> Good luck storming the castle!
>
> Dave Cattley
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *prageeth madhushanka
> Sent: Thursday, January 21, 2010 10:13 PM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Best Software development methodology for driver
> development
>
>
>
> Can’t we follow any agile methodology, for windows driver development ?
>
> I found methodology called Test Driven Development, but it does not cover
> planning,designing and documenting.It only covers development and testing.
> Although I agree , that driver development involves with lot of coding and
> debugging , I also need to find out good methodology which can cover all the
> above phases.
>
>
>
> Aren’t you people follow any methodology for your industrial driver
> development project?
>
>
>
>
>
>
>
>
>
> On Mon, Jan 18, 2010 at 1:55 PM, Hagen Patzke wrote:
>
> On 1/17/2010 6:03 PM, Doron Holan wrote:
> > What makes you think driver development is that special?
>
> Our server administrators.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

James,

I believe you reinforced my point. Testing is ‘verification’ of the plan,
not a substitute for it. Closed loop verification (done frequently) is a
very important part of critical development. But ‘verification’ is
proactive, where-as I take ‘debugging’ to be reactive.

Nice quote. I recall that he did eventually shell out some significant cash
on the bug bounty for TeX & MetaFont.

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, January 22, 2010 12:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Best Software development methodology for driver
development

You can do whatever you want. For what it is worth, Testing never
made
anything better. It only serves to prove you didn’t make it as good
as you
planned.

Or that you planned it perfectly but made a mistake in the execution of
your plan. Mistakes happen, and that is why we test.

Testing should be a part of any development cycle, but if your
development plan is “no plan, just test it until it works” then yes,
you’re doing it wrong :slight_smile:

As Donald Knuth once said “Beware of bugs in the above code; I have only
proved it correct, not tried it.”.

James


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> What makes you think driver development is that special?

  1. Some concepts (for example, IRQL-related constraints) that are unheard of in the user land

2.Compatibility with third-party components that reside in the same address space. Unless we are speaking about DLLs , this problem is unheard of in the user land either.

3.Performance requirements. If you participate in a stack that is meant to service multiple apps the way most stacks do, some inefficiency that you can easily get away with in the UM (because it does not affect anyone, apart from your app) may result in significant performance degradation on system-wide basis
if you allow it in a driver.

These are the very first things that come to one’s mind (I am not even mentioning things like deadlocking the system because of misuse of spinlocks or corrupting memory that is owned by someone else)…

Anton Bassov

>Can’t we follow any agile methodology, for windows driver development ?

I have heard only disastrous stories on Scrum - like the team productivity drop to 1/2 or pre-Scrum, with several doing-nothing “scrummasters” hired.

I have heard only disastrous stories on XP, and the real-world managers I know consider this to be unsuitable for any project except the student labs.

Test Driven Development

Also called “do not think at all, but test a lot”.

With a driver, you have very major requirements on being a “good citizen” in the OS, and very complex surrounding platform full of devilish details :slight_smile:

Choose your process based on the above statement.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

prageeth madhushanka wrote:

Can’t we follow any agile methodology, for windows driver development ?
I found methodology called Test Driven Development, but it does not
cover planning,designing and documenting.It only covers development
and testing. Although I agree , that driver development involves with
lot of coding and debugging , I also need to find out good methodology
which can cover all the above phases.

One of the things that makes driver development somewhat different from
large application development is specifications. Usually – and there
are certainly many exceptions – by the time we start driver
development, we have a specification for what the device below us will
provide (for example, registers or vendor commands), and we have a
specification for the driver model that we need to expose to the layer
above (for example, ioctls). Much of what we do is plumbing – figuring
out how to map the needs of the client above us to the capabilities of
the device below us.

Because of that, the planning and design phases tend to work a little
differently.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
>
> One of the things that makes driver development somewhat different from
> large application development is specifications. Usually – and there
> are certainly many exceptions – by the time we start driver
> development, we have a specification for what the device below us will
> provide (for example, registers or vendor commands), and we have a
> specification for the driver model that we need to expose to the layer
> above (for example, ioctls). Much of what we do is plumbing – figuring
> out how to map the needs of the client above us to the capabilities of
> the device below us.
>
> Because of that, the planning and design phases tend to work a little
> differently.
>
I agree with Tim on this, we are highly constrained versus many software
projects on what we are doing in a driver. Even when it is not constrained
in say the interface, both well known paradigms and good practice lead to
an approach that in many ways is limited compared to say a GUI.

One thing on Tim’s comment, if you can get involved with the hardware spec
before the hardware is completed. Many of the hardware people believe
“our device owns the system” and design things that are hard to impossible
for Windows to support.


Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

Information from ESET NOD32 Antivirus, version of virus signature database 4797 (20100122)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Hmm, it really depends on the kind of the driver, and the entire project and
team structure.
A driver dev may sit within a dedicated “driver team” - or multitask between
either
kernel <-> usermode or kernel <-> hardware/firmware components.
Move this topic to NTTALK, maybe?

But, IMHO, Chris made overall the most comprehensive suggestion. :frowning:
– pa

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>>I would like to know your view on selecting a software development
>>methodology
>
> All off-the-book methodologies are bullshit.
>
> The only valuable books on this are the ones written about the real teams
> who have success in at least 1 - or better more - products. Microsoft is a
> sample.
>
> But note that the practices from successful big company can be unsuitable
> for successful small company :slight_smile:
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>