• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Ship it - to developer??

 
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I feel, in developer point of view, process is not important, his/her whole and sole work is do coding within time.

So does this book is useful for developer??

Thanks.
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By looking at the TOD, I think the book is suitable for developers also.

To me, a developer's work is not just doing coding.... this is the work for a programmer. There are different areas that developers needs to take care of such as the design, testing, development & build environment etc. Besides, there will be one day that a developer, hopefully, will become a team lead.
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with you, Tony.

As a developer, mostly we have to see our project from the high level point of view. Which mean we have to know the design and process flow from the whole application, what our application really does..
Remember that the software is just a tool that support other discipline, like accounting, finance, banking, and so on. Thus we have to know not only the coding technical, but also the businesses.
 
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rathi ji:
Hi,

I feel, in developer point of view, process is not important, his/her whole and sole work is do coding within time.

So does this book is useful for developer??

Thanks.



Process is about creating code in a repeatable way. It sounds like you have a more heavyweight thing in mind. Process should be (in my opinion) just enough to guide the developers, not slow them down.

I've been in shops where there was no process and no-one could build the product except for the one person. They didn't have a build process. So when that one person left, they couldn't build the product. They didn't save much time by not automating the build and they couldn't reliably build the product even with their superstar. A simple Ant script gave everyone the ability to build (and run) the product.

Other shops use shared disks to store their source code instead having a source code management system. They wasted a lot of time figuring out whose code overwrote someone else's.

Having some basic process gives you a framework for interacting with other developers, a reliable way to track bugs, build your product, test your product, etc.


sole work is do coding within time



Not even remotely accurate. Do you share the code with anyone? Do you build it? Do you test it? Do you ship it? How do you know what you are working on now? Next? How do you tell your boss what you did last week?

All process.
 
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rathi ji:
Hi,

I feel, in developer point of view, process is not important, his/her whole and sole work is do coding within time.

So does this book is useful for developer??

Thanks.



Getting it done on time is an excellent objective but for the most part the assigned tasks have been evaluated for feasibility withing the time available. I must have tested, scalable, extensible, impedence matched components that meet the stated requirements; delivering that in a timely manner is even better. To meet those objectives, experience tells us the process is critical.
 
ankur rathi
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Not even remotely accurate. Do you share the code with anyone? Do you build it? Do you test it? Do you ship it? How do you know what you are working on now? Next? How do you tell your boss what you did last week?



Sorry but I am not getting connection of this with software developement process...



Other shops use shared disks to store their source code instead having a source code management system. They wasted a lot of time figuring out whose code overwrote someone else's.

Having some basic process gives you a framework for interacting with other developers, a reliable way to track bugs, build your product, test your product, etc.



I think that is different issue, these basic tools every organization should have, whether they are following any process or not...
 
Rudy Harianto
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Sorry but I am not getting connection of this with software developement process...



rathi,
I assume that you are a programer..
So how could you said that? you didn't do a unit testing? and worst.. you don't even know what're you doing???
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rathi ji:


I think that is different issue, these basic tools every organization should have, whether they are following any process or not...



Process is a word with a lot of different meanings to a lot of different people.

In this context, I meant that the process of 1) only working on the bit assigned to you, 2) getting all code reviewed, 3) checking in the code to the source code management system and 4) sending code change notification.

Having the tools isn't enough... you have to ensure people use them (in some shops!)... that's that one process.

What does proces mean to you?
 
ankur rathi
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I got it right now, Software processes (any one XP, UP etc) tells us to follow certain processes or rules that helps to make standard product.
Use version control tool is one example of that.
[ August 04, 2005: Message edited by: rathi ji ]
 
ankur rathi
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rudy Harianto:


rathi,
I assume that you are a programer..
So how could you said that? you didn't do a unit testing? and worst.. you don't even know what're you doing???



Rudy, don't be rude man.
I never thought that these unit testing, reviews etc are the part of any process.
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rathi ji:
I think I got it right now, Software processes (any one XP, UP etc) tells us to follow certain processes or rules that helps to make standard product.
Use version control tool is one example of that.

[ August 04, 2005: Message edited by: rathi ji ]



Exactly. However, as you're seeing on this board, to many people, process is like a religion.

I find that the really good people aren't rigid about their process. They are familiar with many different flavors and use what's most appropriate.

Here's a quote from the Forward:

Dogma does not mean the absence of thought, but the end of thought.
Gilbert Keith Chesterton (1874�1936)

 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is no doubt that process is the prime mover in delivering code that meets your objectives on time. The process should be flexible such so you can bend it to meet the current situation while maintaining its essential shape. You have to be willing to let your karma run over your dogma on occassion.
 
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jared Richardson:


Process is about creating code in a repeatable way. It sounds like you have a more heavyweight thing in mind. Process should be (in my opinion) just enough to guide the developers, not slow them down.

I've been in shops where there was no process and no-one could build the product except for the one person. They didn't have a build process. So when that one person left, they couldn't build the product. They didn't save much time by not automating the build and they couldn't reliably build the product even with their superstar. A simple Ant script gave everyone the ability to build (and run) the product.

Other shops use shared disks to store their source code instead having a source code management system. They wasted a lot of time figuring out whose code overwrote someone else's.

Having some basic process gives you a framework for interacting with other developers, a reliable way to track bugs, build your product, test your product, etc.

Not even remotely accurate. Do you share the code with anyone? Do you build it? Do you test it? Do you ship it? How do you know what you are working on now? Next? How do you tell your boss what you did last week?

All process.



Unluckily, boss do not care about the process but the output i.e. your software should be function well. Good process adopted but malfunction software developed will let your boss continue to blame you.

Even process helps you to reduce the problems of multi-developer, some problems still exist. For example, each programmer/developer writes codes in different style in the same program, program or system is still difficult to build, trace or debug.

Software development is a complex issue.

Just my view, not means it is true.
[ August 04, 2005: Message edited by: Peter Sin ]
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Unluckily, boss do not care about the process but the output i.e. your software should be function well. Good process adopted but malfunction software developed will let your boss continue to blame you.



First, the boss who cares about how well your software functions should care about the process you use to build it. The two are connected I think.

Second, if you are developing malfunctioning software, you need a better process! A good process will make allowances for testing, code reviews, and other practices that will help minimize bugs.

Even process helps you to reduce the problems of multi-developer, some problems still exist. For example, each programmer/developer writes codes in different style in the same program, program or system is still difficult to build, trace or debug.



Very true. The idea is to adopt the process that helps you the most. It sounds like you haven't found a process that fits you yet.

I must say that most people I know that don't have a good software process think that developing software is much harder that those who have mastered an effective software process.

If you were a carpenter and you never learned how to use your tools, you might think building furniture is pretty hard... and it would be! But building furniture (and software) can be easier, maybe even fun, if you know how to use your tools!

Also, just my opinion! Could be wrong too!
 
Peter Sin
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jared Richardson:


First, the boss who cares about how well your software functions should care about the process you use to build it. The two are connected I think.



It is true if the boss is a technical manager. It is wrong if the boss is non-technical manager. Thus, The two are not always connected.




Second, if you are developing malfunctioning software, you need a better process! A good process will make allowances for testing, code reviews, and other practices that will help minimize bugs.



It is true. Good process helps to minimze bugs but not prevent bugs. Users always demand bug-free software. We need bug-free software development process.




Very true. The idea is to adopt the process that helps you the most. It sounds like you haven't found a process that fits you yet.

I must say that most people I know that don't have a good software process think that developing software is much harder that those who have mastered an effective software process.

If you were a carpenter and you never learned how to use your tools, you might think building furniture is pretty hard... and it would be! But building furniture (and software) can be easier, maybe even fun, if you know how to use your tools!

Also, just my opinion! Could be wrong too!



Can the process help me to build furniture if I am not a skillful carpenter, or even worse I am not carpenter ?

If yes, how ???
 
Tony William
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My view is that Process cannot make your a carpenter over the night. Having said that, it should help to build up your the project management skill, give you something to follow, and review the status (so that you know where you are or how far you are from the destination).

For the team, it helps to improve the team efficiency, how the members communicate etc.
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tony William:
My view is that Process cannot make your a carpenter over the night. Having said that, it should help to build up your the project management skill, give you something to follow, and review the status (so that you know where you are or how far you are from the destination).

For the team, it helps to improve the team efficiency, how the members communicate etc.



Agreed. People don't master tools or design patterns overnight... there are no silver bullets. Anyone who promises differently is selling snake oil.
 
Peter Sin
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jared Richardson:


Agreed. People don't master tools or design patterns overnight... there are no silver bullets. Anyone who promises differently is selling snake oil.



I think the process makes the software development in a manageable manner. To develop a successful software, other considerations should be taken into account. For example, software company should provide training to inexperience programmers for helping them to follow the programming style established by the company. Consistent programmimng style is extremely important in software developement. Otherwise, application developed just likes several small independent applications tighted together. Program bugs cannot be avoided.

This is the aspects of project management skill. No contradiction to the process. Human factors are input to the process.
[ August 04, 2005: Message edited by: Peter Sin ]
 
Rudy Harianto
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Rudy, don't be rude man.
I never thought that these unit testing, reviews etc are the part of any process.



Sorry Rathi, I didn't mean to be rude
I just wonder if any developer don't do the unit testing, cause it has been one of their responsibilities.

And.. hey.. i remember that you started a thread before about the process lifecycle, and there's a review process in there.

But anyway.. forget about me as a rude man! So sorry. I'm friendly, like any other ranchers in this site
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peter Sin:
Unluckily, boss do not care about the process but the output i.e. your software should be function well.



See it as an opportunity - it allows you to introduce a process that fits your needs, instead of having one imposed from someone above who can't fully know what you need.

Good process adopted but malfunction software developed will let your boss continue to blame you.



A good process is one that helps you developing software that doesn't malfunction, by definition. As a software developer, it is your job to think about techniques (and to introduce them) that improve you abilities to develop good software, isn't it?

Even process helps you to reduce the problems of multi-developer, some problems still exist. For example, each programmer/developer writes codes in different style in the same program, program or system is still difficult to build, trace or debug.



Some processes include techniques like a Coding Standard (in fact I think quite a lot do). Don't concentrate on introducing a specific process. Concentrate on solving your problems, and evaluate which processes/techniques are likely to help you.

Software development is a complex issue.



It certainly is! That's why continuous reflection and improvement is so important.

But wouldn't it be boring if it were easy?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rathi ji:
I think I got it right now, Software processes (any one XP, UP etc) tells us to follow certain processes or rules that helps to make standard product.



Well, I'd rather say that they "strongly suggest" them. Blindly following them is unlikely to work well.

As the Agile Manifesto says: "People and their interactions over processes and tools."
 
Peter Sin
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To conclude: What are the benefits of "Process" ? Please refers to "Ship It! A Practical Guide to Successful Software Projects". I just want to test the author debate technique.
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peter Sin:
To conclude: What are the benefits of "Process" ? Please refers to "Ship It! A Practical Guide to Successful Software Projects". I just want to test the author debate technique.



 
reply
    Bookmark Topic Watch Topic
  • New Topic