No Process
No ProcessPreliminary
There's been confusion about what "process" means, and consequently about what NoProcess tries to accomplish. A process, by its meaning in English, is A series of actions, changes, or functions bringing about a result.. Therefore, every software development project will have a process, though it may be unique and non-repeatable. From this perspective, NoProcess is a logical impossibility. However, in the software jargon, the process usually doesn't refer to the individual series of actions taken in a particular project, but rather to a process template: a pre-defined, pre-determined template, usually constructed or designed by process people (a.k.a. methodologists), which is supposed to be applied repeatedly in many projects with the intent of getting some desirable benefits from this repetition. (See also DefinedProcess.)
So, this whole page erects a strawman and knocks it down. Several people have argued that "process", as you use it, doesn't happen in the real world, and that "process", as it's normally used, is an inevitable part of working, and that some agreement on what the process should be among all the people working together is a good idea. The progress of this page seems to be shifting Process to more and more unlikely scenarios, and now NoProcess includes just about anything (including companies running (tailored) RUP etc). Unless you can say what that isn't true, the rest of the argument is getting silly
Well, are you trying to say that the problems listed in the problem section are not real? I think it's safe to assume they're real in many cases. I already brought some examples. It's also true that most teams customize a specific process (RuP,XP, whatever) , and these kind of problems don't exist for them. But you forget that most processes are dogmatic (XpIsDogmatic, but we can argue as well that RupIsDogmatic?), and in many situations they are dictated by the upper management and they're pretty much set in stone. If the premises of NoProcess look like a strawman for you, well you must be as lucky as I am, but for many people they're real.
For the purpose of this page, we'll use process in this sense of pre-defined, pre-determined, process template. Sometimes a process is referred to as methodology or method, hence the name of methodologists. Well-known processes include WaterFall, SpiralModel, RationalUnifiedProcess, ExtremeProgramming.
Therefore NoProcess means: "no predefined process, thank you very much".
Intent
Choosing a process that will guide the development of a software system. Beyond what you read in all books on processes, a process should have the essential quality of not being in the way of software engineers doing their jobs.
Usually in a larger company choosing a process is at the discretion of upper management, subject to becoming one of the infamous company standards (people who can spell outlook know what I mean), but sometimes it is the lattitude of the project manager, and sometimes software engineers get to have a say. NoProcess tries to help them all solve the dilemma, by pointing out that the problem is badly defined to begin with, and the solution proposed so far to this badly defined problem have a great chance of doing more harm than the good they are trying to achieve.
Problem
Software engineers want to do their job, and usually they like to think that they know how to do it. In the meantime, project managers, higher ranked managers and even customers have the legitimate need to control the predictibility of process, to monitor the intermediate results, and to make any adjustments that are needed.
Any software development effort is going to go through more of the same type of activities, even if the order of them, the accent and the focus, sometimes the name used might difer from methodologist to methodologist. The methodologists have done a great job of confusing things in this matter, but let's argue for the purpose of this discussion that the core activities of concern are:
To these core engineering activities, processes add an organizational dimension: how the team is structured, how the project is managed, and stuff like that.
For each of these activities, there's a whole deal of scientific literature, engineering experties accumulated over the years, and for each of those there's a whole science to it, menaing a wide palette of techniques, methods, scientific knowledge, and even engineering heursitics that a software engineer can apply in order to get the job done. Of course, different solutions are better, depending on the context: the problem to be resolved. Most of them are counter-productive if applied in the wrong context.
It is the personal responsibility of the software engineer to have and develop a significant cultural background in these disciplines of software engineering. We'll call them horizontal disciplines, as they refer to slices of the development effort as opposed to processes which are vertical.
Now, what does a process do ? Not talking here about the ideal process, that's another discussion, but the nowadays hypes: it comes and it steals away all this beautiful diversity, and for each of those horizontal activities, it picks a particular narrow way of doing it.
And great chances are, that the software engineer will be prevented from doing his job the best way he knows because what was supposed to be his choice in dealing with the problem at hand, became the choice dictated by the process, and most likely the wrong choice for that matter. We have here a ProcessMisfit: the process was not designed to meet the characteristics and challenges of a class of problems, and in particular the choices it makes are wrong for the problem at hand. The problem was signaled by MichaelJackson in SoftwareRequirementsAndSpecifications.
There are lots of examples of the misfits. See ProcessMisfitExamples?. As a matter of fact, one only has to consider the wide diversity of problem classes (database driven business application -- which I mention first because most processes seem implicitly to focus on this one, concurrent and real time systems, development tools/compilers, operating systems, databases, CAD/CAM, office application, image processing, scientifi/numerical, etc, etc, etc) and the wide range of horizontal options available, and more importantly the fact that none of the current known processes link the chosen solution to the problem domain and justify this in any way.
In MichaelJackson's words:
AlistairCockburn pointed out that this assertion no longer holds true, that there are processes that have a well defined domain of applicability. See ProcessDomain.
Solution
Choose NoProcess instead (advice to project managers, ideally ex or active software engineers, we don't expect upper management to understand very easily).
Send the methodologists back to the table, and ask them to stay away as far as they can from making technical choices. If their product is to be used by manager, please don't interfere in a negative way with the engineering job of software engineers. Let them focus more on organizational and management issues. Horizontal choices should ideally be of no concern to methodologists.
By chosing NoProcess, you risk nothing from a technical point of view. If the software engineer deems necessary he's free to do CodeUnitTestFirst, PairProgramming, ListenToTheCode, UmlDiagrams, UseCases, UserStories whatever technique in whatever process.
What is more important, I believe is that the reasons you want to have a process in the first place (management, predictability, visibility, etc ... ), are orthogonal to how engineers do their work or how the processes tell them to do.
Resulting context
You'll have a much more flexible development process (not process template). The accent will be put on the responsibility and the professionalism of the individual software engineers. They will spear a lot of time wasted on reading process books, in order to comply with the predefined process, and they will use that time to further study the individual activity.
Believe it or not, software engineers love individual freedom and responsibility. They take pride in their work, and the strive to do it best, to continuously improve. Their work will be better.
Contraindication
If you have a lot of software engineers that don't have the necessary cultural background and experience to make informed horizontal choices, maybe it's better to have a process come with the predefined solution.
Rebuttal (please incorporate these ideas into the above)
Many software engineers are happier when they understand what is going on. Chaos is fun and interesting sometimes, but many software engineers get into study of process because they are frustrated with the lack of discipline and teamwork, and the loss of productivity that comes from having individuals all do their own thing, and want to know if there is a better way. Study of process is how I strive to do better and to continuously improve. A good process is not just a tool for managers--it helps the engineers do what they want to do.
The lack of discipline and teamworks comes conmes anything but NoProcess. NoProcess doesn't mean the software engineer is not responsible for what he's doing, on the contrary, he/she should take more responsibility.
My colleagues and I have our own process. It's not RUP, or XP, Objectory, or OMT, or Fusion, or anything else from a book--it's just a set of practices that works for us. We use this process on all our projects, tailoring it and improving it as necessary. Now, are we guilty of following a pre-defined process (and dooming ourselves to all the misery that entails), or would you consider us to be doing NoProcess?
I think that it proves my point. You probably have your reasons not to be happy with the ready made ones. The fact that you have the liberty to ignore the industry's standard best parctices, already says something, most people don't have that kind of liberty. What happens if in the next project you'll meet a different situation, you'll probably change your process on the fly, there's no one telling you not to, right ?
Your counterindication is an insulting mischaracterization, so I'll return the favor. Here's the true counterindication to NoProcess: If your software engineers exhibit professionalism, a desire for improvement, and are willing to take responsibility for their work, rather than blaming all their problems on misuse of something they took out of a book, then informed use of a process template can have benefits. NoProcess is suitable for undisciplined hackers who don't understand (nor want to understand) how they or their peers approach their work, and want to only do the "fun" parts of programming while avoiding the hard work.
For the "undisciplined hackers" to understand how their "peers do approach their work", it will take for the said peers to match their process to the problem, which it doesn't happen when the said peer are methodlogists, and when the experience they are doucmenting is the process. Rest assured that "undisciplined hackers" are very curious to find out how their peers do their work. My peer DonaldKnuth has a lot of interesting things to say on how to code for example. My peer MichaelJackson has a lot on RequirementsEngineering. But we've been utterly disappointed by the peers who sell the vertical enchilada, so we've decided not to follow their advice until they have something interesting to say. There's only limited time to take care of one's continuous education, and books on processes are the worst investment of that time, at least for the "undisplined hackers", "cowboy coder" and the likes. Inspite what you might think, we still yake pride in our job, we do it professionally and we get results.
Something you either don't understand or don't want to admit is that process templates are intended to be tailored as necessary for a project. Just because some book you read says "To follow this process, you do step A, then step B, then step C" doesn't mean that you must do it that way. Rational's people are giving seminars on how to make RUP more lightweight, by eliminating a lot of the work. Does that mean that Rational is telling people to not do RUP? No, it means that the "essence" of RUP is independent of whatever arduous set of steps is listed in a book. Similarly, if you want to do XP but you want to limit the number of UnitTests you do, no one is going to stop you.
Are you trying to say that all of them are in fact NoProcess? That you are free to replace no matter what to adjust to the situation in front of you? I'm affraid somebody will say [[you aren't doing ...]]. I'd be happy to take such kind of a NoProcess process, and substitute it for NoProcess which sounds too radical.
The problem with books about process is that many readers take every sentence as literal, unchangeable, holy scripture that one must accept without argument or thought. Those people are idiots, and their failures should not be considered as evidence against process. Almost every respected authority admits that the idea of a totally predictable, repeatable process is silly. That doesn't mean process is worthless--it just means you have to apply it intelligently and accept the limitations.
-- KrisJohnson
Further discussions:
NoProcess happens anyways.
Don't fool yourself, most software engineers worth their title will do NoProcess anyways: they have the ultimate choice in how to do anything they do on a project. If I'm not happy with how RuP dictates me to approach a specific problem (database design is my favorite), I'll do it my way anyways, even if I'm supposed to do RuP.
So let's just cut the crap.
I disagree. Any software engineer worth the title will do what is best for the project and the team as a whole, and is willing to settle for a little imposed discipline to fulfill those ends. If a software engineer doesn't like the process, the engineer will fix the process, not just throw it away. Face it: coding is the easy part--the hard part is getting your code and everyone else's code to work together. -- KrisJohnson
Let's put it this way: in some aspects, some processes are so rotten and corrupt, that the best way to deal with it is to totally ignore them . It's not about little imposed discipline, doing things in not necessarily the best way so that the whole team can speak the same language, it's about doing things the wrong way. Would you have any ideas how many "object architects" formed under the RuP come up with bad database designs, and bad performaing transactional code? Is it because they are not good software engineers? I don't think so. But having a process of the authority of the RuP, stamped and approved and set as company standard, already creates a tremenduous psychological and political pressure. It takes more than a technical judgement, to fix the process, if at all possible.
Most people even if they know it's contrary to their training, will take the little imposed self discipline, others will never even bother to look before the books with the three amigos stamped on them , they'll nwever know something is wrong until the problems start to appear, and even then they think it was their fault to begin with.
The political pressure of a pre-defined process , sometimes set in stone as company standard, is no little joke that a software engineer can cope with easily. To change a pre-defined process is an uphill battle. What if we make it downhill? NoProcess is assumed, and because the software engineers know their job and are professionals, of course they studied what Rational has to say, and they apply it only if it fits the problem. What is best for the project and the team as a whole is always getting the job done. -- CostinCozianu
NoProcess works.
It doesn't have any reason not to work, because all the options are open. It is also of very little value, by MJ's observation because it applies to everything, it has no real value to any particular situation. But its value is that it prevents the evil of processes. The real value cannot be in the process, it can only be in the science that applies to the horizontal activities: requirements, design, coding and QA. A predefined process diminishes that value, while NoProcess sets it free.
And because NoProcess it's not a process, is the negation of process, it doesn't have to fit the problem. Whoever wants to design a process, that one has to worry about problem fit.
Furthermore, I've seen with my own eyes project managers that didn't do no RUP, no XP, no nothing. They were only concerned with deadlines, bug resolutions, who's doing what, tracking progress, and all the things a project manager needs to do. They just trusted the skill and the professionalism of their team. It was an absolute pleasure to work for them. I'm convinced that many others around here witnessed similar situations.
Hasn't anybody around here worked on successful projects with NoProcess at all? At least everybody must have seen it in practice somewhere, regardless whether he was directly involved and whether the effort was successful or not.
I know I did. I just love it. It works like this : you gotta do what you gotta do.
Requirements, architecture (only if an architect exists and it so pleases him to do architecture), coding, a bit of design, a bit of database, a bit of testing, QA, documentation, a bit of politics with ther management only when it's needed. All these activities are science and art in their own right and you need a lot of knowledge, flexibility and common sense to see them through. What you don't need is a preachy approach: you gotta do it this way. You need is to have a bunch of people that are good at what they're doing, have fun together, and take pride and responsibility in their work.
And forget about ProcessImprovementTools. The only things that needs to improve are the skills and knowledge of each individual and the team as a whole. -- CostinCozianu
Concerning the preachy approach, while there are some who preach their approach as though there is no other way on earth, most just offer helpfully what worked for them (and yes, sometimes what they think will work the next time as though they had already tried it -- watch out for those!). However, many software professionals I have worked with cannot understand the concept of a guideline. They think in terms of mandates, and so misinterpret the spirit of helpful advice.
I've also noticed -- I swear this is true in every case -- that the people who make the biggest stink about creeping bureaucracy as lowly programmers are the first to levy rigid mandates to their way, once "in office". No wonder they were so scared back then. They fantasized that they were working for themselves.
No process, no bullshit, just getting the job done. Sounds good, let's do it for as far as it takes us. But when the individual skills and talents fail to automatically coalesce into the ideal project performance, you will find programmers and managers alike discussing process, perhaps without using that word. It's a natural transition. So be careful to distinguish between "no process" (an unlikely state of affairs under any circumstances) and "no awareness of process" which seems to be the current state of the practice for many groups.
NoProcess might work fine for small projects of two or three people who work well together. But once you have more people than that, or have to bring a new person in, then you need to have some "rules" and "responsibilities", and then you have a process.
"Do what you've gotta do" is fine, but how do you know what you've gotta do? Are you asking the customer what they want, and figuring out how to implement it? Then you have a process. Are you keeping track of bugs, prioritizing them, and assigning them to people to fix? Then you have a process. Do you always check code into the source code repository before doing a production build? Then you have a process. If you are out of the office, is it possible for someone else to fix a bug in your code? Then you have a process.
The benefit of formal process models is the sharing of information about things that work, and things that don't work. Everyone who decides to "buy in" to a process needs to accept the responsibility of evaluating that process in relation to their own work. It's certainly true that following the rules of a formal process without understanding it or thinking about it can lead to bad outcomes. But that is your fault (or your bosses' fault), not the fault of the authors or proponents of the process. There's only one thing you always gotta do, you gotta think.
-- KrisJohnson
The notion of NoProcess reminds me of those companies where there are no OrgChart?s or titles given to anyone, supposedly because this keeps the organization flexible and avoids political games between different departments. In reality, such an company has a hidden, byzantine organization that requires all of its members to be skilled politicians to get anything done, and the organization changes depending upon who happens to be in the office at the time. The real reason for such an organization is that it provides the company's owner absolute authority over everything, as no authority has been officially delegated to anyone else. The same goes for a software development organization where the managers insist that there be no formal process: it just lets the managers order people around without giving those people any way to determine how their work will be judged, nor any way to predict what the managers are going to ask for next, nor any way to discuss how the organization's performance can be improved. -- KrisJohnson
Beautiful observation.
I'm starting to edge away from the NoProcess attitude. What I first felt was liberating, I now see can at best be interpereted as a negative heuristic. As such it offers no real guidance. I now believe that large to medium sized projects must have a planned structure. However, I maintain my former liberal stance as regards what that structure should be (see XpIsDogmatic).
This minor adjustment to my thinking seems disappointing until you take a look at the richness and diversity of the possibilities on offer. For example, WaldenMathews has now added a few twists that bring even the WaterFall model back into play. -- ChrisSteinbach
Of course, it offers no real guiddance. The whole idea was that the real guidance was to be found in the horizontal domains of software engineering. For requirements, you need to read MichaelJackson and others. For information modeling and database design you go to other people. For the design of code structures to others. For testing and QA to others. You form a solid cultural background of what all these people have to say, then you meet your problem. Go into your cultural background and see what combination of approaches should likely work for the current situation.
But if you buy into something like RuP the whole idea is already that you're already architecting objects, you're doing requirements strictly in terms of use cases and objects, and so on. For God's sake, UML doesn't even have the concept of function, how am I supposed to "design" a code structuring based on functions as the essential abstraction. If you buy into XP, you won't have a chance to start with a proper database design, because you're expected to build it story by story, happily refactoring all along. Maybe I don't feel like wasting my time writing unit tests, cause I can prove instead that my concurrent code works, and exhaustive UnitTesting is next to impossible.
So yes, let's acknowledge the diversity and richness, but it's exactly NoProcess that allows diversity and richness. Most other processes en vogue today commit the deadly sin of slicing a very thin vertical piece in the whole range and diversity of software engineering tools and approaches. They do go into technical details, when they should stay out. -- CostinCozianu
You make some good points. Maybe the problem I have is with the name NoProcess. It is suggestive of anarchism and I don't think either of us was trying to support NoStructure?. -- cs
XP is a kind of NoProcess, but maybe it's not suitable for you; RUP is a kind of NoProcess, but maybe it's not suitable for you; All agile processes are NoProcess, but maybe they are not suitable for you, I think.
Anyway, I love NoProcess, just as I love WuWei. --GuangjunMa
[[ For the old discussion, see NoProcessDiscussion. Refactoring is still in progress, please help. All the ideas should be brought back here, but some repetitions should be cut and the organization should be improved.]]
EditText of this page
(last edited October 30, 2010)
or FindPage with title or text search