Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is Process Killing the Software Industry?

timothy posted more than 3 years ago | from the about-those-tps-reports dept.

Programming 460

blackbearnh writes "We all know by now that Test Driven Development is a best practice. And so is having 100% of your code reviewed. And 70% unit test coverage. And keeping your CCN complexity numbers below 20. And doing pre-sprint grooming of stories. And a hundred other industry 'best practices' that in isolation seem like a great idea. But at the end of the day, how much time does it leave for developers to be innovative and creative? A piece on O'Reilly Radar argues that excessive process in software development is sucking the life out of passionate developers, all in the name of making sure that 'good code' gets written. 'The underlying feedback loop making this progressively worse is that passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to "make" their programmers write good code. That just makes morale worse, and so on.'"

Sorry! There are no comments related to the filter you selected.

"Creative" (5, Insightful)

Anonymous Coward | more than 3 years ago | (#36092244)

If you want to go off and do your own thing, fine. Have at it.

But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

Re:"Creative" (4, Insightful)

Entrope (68843) | more than 3 years ago | (#36092346)

This is dead on. Every software-developing business needs to decide its own process needs. Even if they are developing safety-critical code that has to pass rigorous certifications (FDA, DO-178B, etc), sane people do not order everything on the process menu. However, an organization does have to look at its market, its code base, its structure/culture, and its history to figure out what kinds of process it should use. Sure, having a defined process means developers spend less time throwing code at the wall, but the code they do throw usually sticks to the wall better and longer, and they usually feel good about that.

If someone seriously and repeatedly complains that following the process kills their passion, it is due either to a failure of that analysis or them being in the wrong organization. As an software developer and occasional manager and/or process guy, I have seen both cases. I have also seen cases where having a defined process helps channel creativity. Good process tools help you focus on the right parts of the problem; for example, having a template for a design description that identifies particular subjects to focus on, and may suggest areas that have been rabbit-holes in the past.

Re:"Creative" (5, Insightful)

heathen_01 (1191043) | more than 3 years ago | (#36092602)

This is dead on. Every software-developing business needs to decide its own process needs.

This is just another cargo cult problem. Managers, seeing that another company/team use process X on a successful project, decide to implement the same process for their team. However no process will make a difference if the developers have been directed to build the wrong solution in the first place, even if the code is 100% bug free.

Re:"Creative" (1)

HungryHobo (1314109) | more than 3 years ago | (#36092730)

I've heard some horror stories of companies which, as you say, "order everything on the process menu".
Everything has to be signed off on by 20 people who have no relationship to the project, integration networks that a guarded more closely than production networks and even trivial projects take years to production etc etc.

I know it can be painful writing documents which you know nobody will ever read because the one thing the org I last worked at lacked it was a good documentation tracking system so people spent huge chunk of their time documenting their actions but when things went wrong their either wasn't enough time to wade through all the poorly labeled crap or the documentation had been lost.

Quick general tip for anyone working small app development in a large org: if you have documents, even if there's some place they're supposed to go as well just throw an extra copy into a "doc" file with the application if you can.
It's for the sake of the guy 10 years down the line when nobody remembers where the original docs went.

Re:"Creative" (1)

HungryHobo (1314109) | more than 3 years ago | (#36092782)

there not their*2

god I need to sleep more.

Re:"Creative" (4, Interesting)

RyuuzakiTetsuya (195424) | more than 3 years ago | (#36092780)

My thoughts exactly.

I worked basically in the skunkworks for an ISP's call center. We developed the CMS that handled all of our policy and procedure documentation, we developed neat tools that interacted with our IVR for outages, displayed coverage maps with said outage data, and various little tools here and there.

When we started, we weren't bound by our IT department's change management process. As our tools grew and as their usefulness permeated our business, we started to get noticed and before we knew it, we were being held to the same standards for process as teams who developed tools like our CRM and our internal ticketing system.

The whole point of our skunkworks was to be nimble, efficient, and effective on smaller projects those teams didn't have the ability to take on due to commitment to other projects. Yet, as IT's demands for compliance grew, all of our advantages went away. Soon, i found myself having to answer, "Why is late?" and invariably the answer would be, "Oh, it's held up by IT's Process. It'll be three weeks." Managers weren't happy. I REALLY wasn't happy and stressed and my user base wasn't happy either(Although my user base had a certain degree more sympathy than management did).

It sucked the life and effectiveness out of our team.

When layoff time came a month ago, on paper, we looked like were banging rocks together, and bunch of us were laid off, with those teams that didn't have the time or resources to build these tools in the first place having to absorb yet more work.

(note: I didn't mind the particular IT policies, they made sense, but, I felt like a sense of scale was lost when it came to our projects. Oh well.)

Re:"Creative" (3, Interesting)

Barbara, not Barbie (721478) | more than 3 years ago | (#36092786)

The usual problem is bosses who either don't want you to follow a process, or they don't want to have to bother with the work that they would have to do.

How many times have you been told to forget updating the documentation or specs (or worse, "what documentation?"), or you're told to "just make it work"?

Or you've sat in a meeting during a review of the current project, and it's just a waste of time because it's like management is just filling up their buzzword bingo card by spouting various processes that could be used to improve things - and you should implement them and then tell them how (or if) they work. (as long as THEY don't need to be part of it beyond reading a half-page summary every once in a while)

Often, these are the same guys who will demand a 120-page report on the current state of the project "and it needs to be in my inbox in 48 hours" - and then "tl;dr" it.

In many cases, their reluctance to follow process is because it would show that they don't have the understanding to make a meaningful contribution to the process. If they don't tell you what to do, it's not their fault when the horse pucky gets into the HVAC. They'll blame you for not following their ad-hoc "management process."

Like the boss who dumps 3 different emergencies on you at the same time, and then gets all snarky because you didn't fill in the detailed spreadsheet of what you did every 10 minutes ... because now he can't use it to figure out how to fill in his time sheet of what he did all day, because he never keeps track of his time - just works it out backwards from yours.

Most developers would be more appreciative of processes if they weren't used as a weapon by the same management who refuses to adhere to sane processes themselves. For them, it's just CYA all the way down ...

Re:"Creative" (1)

realxmp (518717) | more than 3 years ago | (#36092400)

But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

Keeping any aircraft/metro/car safely in the air/on the rails/road does require a process yes (specification in Z etc), but it needs to be balanced with a certain degree of interest in your subjects that only comes from enthusiasm. In the real world no specification is 100% complete and there are often times when a coder has to make a judgement call and send a memo asking for clarification saying "This was unclear I did this, confirm it is correct" (blocking until you get an answer isn't usually an option owing to deadlines). Quite often these aren't answered and it's only the programmers own interest in what they're writing and passion that ensures the correct decision is made. Keeping that passion and enthusiasm is nigh on impossible if EVERYTHING is process.

Re:"Creative" (0)

Anonymous Coward | more than 3 years ago | (#36092520)

So keeping a 777 in the air is something that you should complete without having your specification 100% complete? I take it you haven't been a member of any team that develops mission critical software then. If the software for a pacemaker fails because of your methodology/process (yes, lack of process is also a process), can we sue you for the loss of life?

The level of process/methodology that is used on a project needs to fit the parameters of the project. The more critical it is, the more structured and disciplined the process needs to be. Now, do you need to use CMMI level 5 on a university project, no, but then that would be the misuse of the process, not that the process is bad.

If something in the spec is unclear, then maybe you should kick it back during the review process to ensure that it is clear. If it isn't clear, then just maybe the person writing the spec didn't understand the requirement that came from the business, and in line, just maybe the person that wrote the requirement didn't really understand what the requirement was.

In short, software development is not an art, it is a career. It is OTHER peoples money you are playing with, not your own. If you want to be artsy fartsy with your own money, so be it, that is your choice. But that money that is being invested, in part to you, in part to others on your team is not being invested to piss around with. It is being invested to make a product that is to make the organization money.

Oh and haven't you EVER been on a project where others have gone creative and you have had to deal with it? NO, then you have never been in the real world. Sorry.

Too many god damned clueless prats who think that everything is about them and not the greater team (that is the business that is paying your bloody salary). If you get the feeling that I am pissed off with this attitude, then yeah I am. I have had to deal with 'gone creative' attitude far too many times and the extra cost associated with it.

Re:"Creative" (1)

Anrego (830717) | more than 3 years ago | (#36092490)

Obviously the amount of process is going to be proportional to the number of metric ass-tonnes of shit that hit the fan if something goes wrong, but I still think there is room to at least choose processes that don't overlap too much or interfere with each other. In the aerospace, defense and medical industries, it's all about more and more process to make everyone feel better (and produce better software and such..). Bug gets caught in one phase of testing.. add more process so it would have been caught earlier!

I would add however that excessive process, or more destructively, processes that fight each other, can not only hamper creative solutions, but can prevent people from making enhancements due to the excessive amount of "other stuff" that has to change in addition to the code. I would certainly say that a lot of process gets tacked onto stuff that's non critical, mostly for buzzword purposes, which is I think mainly what this article is speaking to. Having a process in place so management can say "we do agile cloudsource coffeecup modeling!" or whatever is always bad for the guys who have to work in that environment.

Re:"Creative" (3, Insightful)

donscarletti (569232) | more than 3 years ago | (#36092550)

If you want to go off and do your own thing, fine. Have at it.

But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

You need creativity to write something accurate, elegant and easily reviewed, tested and verified. You need discipline to actually do the review, testing and verification steps. Both are equally important if you want something solid and delivered on time.

Re:"Creative" (2)

vlm (69642) | more than 3 years ago | (#36092626)

That is the type of scenario that we need discipline, not creativity.

Its a mistake to think discipline and creativity must be bipolar exclusive opposites. Anecdotes from all parts of that venn diagram claimed as "universals" are not really insightful, either. The best solution will maximize both within constraints and specs, assuming you have the discipline to provide any, and enforce them.

Re:"Creative" (0)

Anonymous Coward | more than 3 years ago | (#36092650)

If you want to go off and do your own thing, fine. Have at it.

But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

Amazingly, the code written to keep 777s in the air was written before Agile came about. You'd think we'd have more crashes, eh?

Re:"Creative" (1)

pedantic bore (740196) | more than 3 years ago | (#36092658)

Please accept this comment in lieu of mod points, which I do not have at the moment.

Re:"Creative" (-1, Flamebait)

cpu6502 (1960974) | more than 3 years ago | (#36092750)

>>>777 safely in the air. That is the type of scenario that we need discipline, not creativity.


Never mind. My IP can be traced. Let's just say: Airplane Process assurance has as little to do with "discipline" or "assurance" as Bush's promise to balance the budget, or Obama's promise to not start any new wars.

Does anyone know the Happy Medium? (3, Insightful)

AdmiralXyz (1378985) | more than 3 years ago | (#36092254)

I'm all-too-aware of this issue and how quickly it sucks the life out of you and prevents anything from getting done, but at the same time obviously having no process doesn't lead to stellar code either. My question is, do any of you work in a place where you think you've struck the right balance? What are you doing?

Re:Does anyone know the Happy Medium? (2)

CynicTheHedgehog (261139) | more than 3 years ago | (#36092284)

Good issue tracking, short iterations, and daily stand-ups to discuss issues. Assign mentors to junior developers that you know need help, and have the mentors spot check the code. Let the more experienced developers choose the stack, define the interfaces, an create prototypes, and then hand those off as a template for other developers to follow.

Re:Does anyone know the Happy Medium? (4, Interesting)

tripleevenfall (1990004) | more than 3 years ago | (#36092330)

Where I used to work, (I posted elsewhere here why I left development), part of the problem is that the attitude was always "another small task won't hurt engineering". "Another step in this process is not a big deal"... until there are so many of these tips and checks that you aren't doing anything else but these microtasks.

I think that most places have big problems going cheap on staff. They cheap out on testing staff. They cheap out on training for the support people. They cheap out on resources for environments. All of these things cause more weight to be placed on the developers.

And it's all by design... develppers are replaceable, in many companies' view - more are churned out of college annually and they only have a 2-5 year lifespan on average. Rather than expand budgets to reflect what development really should cost, they simply treat developers as disposable resources on a burnout/replace cycle.

Re:Does anyone know the Happy Medium? (0)

Anonymous Coward | more than 3 years ago | (#36092564)

I've found that processes which are easy to digest work well. At the very least, have the massive 100+ page document available, and have a "coles notes" version (or multiple versions) that people actually read.

I'm also a huge fan of checklists. Have a checklist for each phase... make it a requirement for everything to be checked off (or an appropriate excuse filled in). When stuff makes it through a phase with mistakes... add more stuff to the checklist. In addition to making sure nothing gets missed, it can act to kind of guide people through the process and make things a lot less stressful.

Re:Does anyone know the Happy Medium? (2)

vlm (69642) | more than 3 years ago | (#36092722)

My question is, do any of you work in a place where you think you've struck the right balance? What are you doing?

Think of the brilliance of the parental strategy of having once kid cut the cake and the other kid select the slice? The way that cuts down on squabbling about who got the bigger piece of the pie? Application of this principle to coding/coders vs testing/testers seems obvious... Doesn't it?

An inherently self stabilizing and self balancing system always works better than one managers best (possibly misguided) attempt at neo-authoritarianism.

Also for gods sakes make everyone in management read Fred Brooks book and fire anyone who disagrees. Absolutely timeless meta-advice to frame the problem.

Budget (4, Insightful)

mrops (927562) | more than 3 years ago | (#36092826)

My problem with process has always been budget. Folks higher up budget on the basis of minimal process and expect full process. If you want 70% unit-test coverage, that is twice the time the code would have taken if you did not write unit test. Add 3 times the time if you want good integration tests to go with it.

Unfortunately, this makes a project costly. The problem occurs if the PM then demands full process when the time is not accordingly budgeted for it.

Release cycles also become long.

Over my head (2)

Apple Acolyte (517892) | more than 3 years ago | (#36092264)

70% unit coverage? CCN complexity 20? Pre-sprint grooming of stories? This article is apparently not meant for a general geek audience. Can someone translate these terms into something that non-professional programmers can comprehend?

Re:Over my head (5, Informative)

Derkec (463377) | more than 3 years ago | (#36092344)

70% Unit Coverage:
        -- You've written code level tests that flex 70% of your code checking for regression failures.

        -- Technical term you can look up, but basically it's a measure of how many decision points are in a block of code. Less decision points is simpler. Too many and you may have something difficult to test and difficult for a programmer to understand. Higher complexity generally means more risk and a higher need for testing of various types.

Presprint grooming:
        -- A "sprint" is a time block set aside for development. Usually 2-8 weeks. The goal is declare what you're going to get done in that time and not change the requirements during that time. Between sprints, you can change your processes, "groom" stories (tasks that describe things in a user experience way generally).

Test driven dev:
        -- When writing a new feature, right a test for that feature first and you're close to done when the test passes and you haven't broken other tests.

Re:Over my head (1)

Anonymous Coward | more than 3 years ago | (#36092836)

That is not TDD.

You are allowed to break the feature down into tiny pieces and write a test for a tiny piece before doing the implementation for that piece.

At the feature level it's more like "test in parallel" than "test first", unless it's a really small feature.

Re:Over my head (1)

stewbee (1019450) | more than 3 years ago | (#36092350)

"70% unit coverage" means that your production code before being integrated should have touched at least 70% of the code. The complexity number is related to how many branching statements there are in a single function/program. You can look up how they compute it, but it involves basic graph theory. I have no idea what "pre-sprint grooming" is though.

Re:Over my head (1)

Anrego (830717) | more than 3 years ago | (#36092598)

I have no idea what "pre-sprint grooming" is

It's from the agile crowd. Basically the idea is you have periods where you do just dev.. and periods where you look at processes and make changes to your use cases and such. Sounds weird to me (if I find something wrong in week 1 of dev, I want to fix it now, not plow through and go back later) ... but my understanding of it is foggy and even the most messed up approaches can claim a success story _somewhere_.

Re:Over my head (1, Redundant)

mevets (322601) | more than 3 years ago | (#36092470)

70% - out of every X lines of code, 70% of them are actually executed in test. For example, code might contain something like:
if (month == 12 && day == 25) {
          printf("Joyous Season of Light\n");
However, without cheating, this holiday greeting would be untested on most testing days.

CCN - a way of expressing the logical complexity of program code to flag potential trouble spots. Google Cyclomatic Complexity

pre-sprint grooming - google agile development.

Coverage is a good thing, although 70 seems pretty lowball.

CCN is well dressed snake oil; however it has a more interesting side effect - low CC# programs are often easier to read.

Agile is unpretentious snake oil.

Re:Over my head (1)

heathen_01 (1191043) | more than 3 years ago | (#36092662)

70% - out of every X lines of code, 70% of them are actually executed in test. For example, code might contain something like: if (month == 12 && day == 25) { printf("Joyous Season of Light\n"); } However, without cheating, this holiday greeting would be untested on most testing days.

Using techniques like IOC and Mock classes that snippet of code could be tested every test run.

In a nutshell (1)

theshowmecanuck (703852) | more than 3 years ago | (#36092270)

Yes. When you need to spend almost as much time learning how to and using the tools, processes, and configuration than actually producing code... then yes. And no it doesn't always help make better code. A lot of the time it takes time away from making code good.

Re:In a nutshell (3, Insightful)

Anonymous Coward | more than 3 years ago | (#36092530)

the problem is always the same:

how can manager get bonus lowering staff costs?

they get cheapo developers and throw the top notch methodologies at them in the hope those will make up for the devs inexperience and plain incompetence.

that gives in turn a bad name at methodologies and tools, because cheapo devs cannot understand nor benefit fully from them. what use is a pmd output to a guy who's never got the difference between passing by reference and passing by value?

and there are, lots of them. just check any java forum.

yet, the truth is that some of the methods and tools are a good helper for good and also top notch developers. if you work with the tools, and not by the tools, you can catch way more common errors, be notified of piece of code that may need some attention because grew too much in scope and features and lot of other small things that make your life easier.

but it has to be a cereful choice, based on your experience and knowledge, not something imposed because it's the last buzzword.

The solution is simple... (2, Funny)

Old Sparky (675061) | more than 3 years ago | (#36092272)

Get rid of management!

worrysome wed., unproven body count rising (-1)

Anonymous Coward | more than 3 years ago | (#36092276)

women & children 1st? disarm. tell the truth. the sky is not ours to toy with after all?
you call this 'weather'? what with real history racing up to correct
itself, while the chosen one's holycostal life0cider mediots continually
attempt to rewrite it, fortunately, there's still only one version of the
truth, & it's usually not a long story, or a confusing multiple choice
fear raising event.

world wide disarmament is taking place based on the pure intentions of the
majority of the planet's chosen to be depopulated, population. as the
biblical fiction based chosen ones have only one ability, which is
destruction for personal gain, they just don't fit in with all the new
life extending stuff that's we're being advised to ignore. life likes to
continue, advance etc... deception & death appear to have similar

wouldn't this be a great time to investigate the genuine native elders
social & political
leadership initiative, which includes genuine history as put forth in the
teepeeleaks etchings. the natives still have no words in their language to
describe the events following their 'discovery' by us, way back when. they
do advise that it's happening again.

Due to excessive bad posting from this IP or Subnet, anonymous comment
posting has temporarily been disabled. You can still login to post.
However, if bad posting continues from your IP or Subnet that privilege
could be revoked as well. If it's you, consider this a chance to sit in
the timeout corner or login and improve your posting. If it's someone
else, this is a chance to hunt them down. If you think this is unfair,
please email with your MD5'd IPID and SubnetID,
which are always changing, you butthead
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

The one process to rule them all (5, Insightful)

Tribaal_ch (1192815) | more than 3 years ago | (#36092278)

Karma be damned, this is relevant [] to TFA:

Re:The one process to rule them all (1)

syousef (465911) | more than 3 years ago | (#36092646)

I'm passionate about programming, but not enough to have sex with my mother. I guess I'll never be a programming motherfucker.

Process, wot's that? (0)

Anonymous Coward | more than 3 years ago | (#36092280)

Come and work for my company, we have virtually no process whatsoever. We get given some vague sketches and told to go develop. We have no standup meetings, no pair programming (people on the same team never speak to each other and everyone develops to their own standards, you can get 3 different typoes of MVC framework in the same project), no coding standards, there isn't even a QA department (that's what the client is for innit), just code it up and crank it out. We even deploy to live servers when needed.

Re:Process, wot's that? (0)

Anonymous Coward | more than 3 years ago | (#36092456)

At the company I used to work for we did all our work on live and was not able to work locally. That's one of a number of reasons that I left.

This is why I left development (4, Interesting)

tripleevenfall (1990004) | more than 3 years ago | (#36092286)

This is why I left development. After 5 years working at a software company I found that only 10% of my time or so was spent writing new code, which is the only thing I really liked about the job. The rest of the time was spent in meetings, wading through red tape, reviewing others' code, doing maintenance on the (junkpile) legacy system, doing remedial training for the front-line tech support staff, and the 5 million small tasks that have nothing to do with why I went into the career field.

Re:This is why I left development (1)

Vectormatic (1759674) | more than 3 years ago | (#36092480)

What did you switch too? i find myself doing pretty much the same thing (lots of non-coding compared to actual coding), yet i cant think of something else i'd really enjoy (and which would provide me with the same income)

I'm not fed up enough to switch careers by a long shot, but those meetings do get a bit old..

Re:This is why I left development (1)

tripleevenfall (1990004) | more than 3 years ago | (#36092502)

I went to work for one of our clients, administering the system I used to do development for. The starting salary was a bit less, but negligible. The regular hours and good work environment more than made up for the small loss of income.

Re:This is why I left development (4, Informative)

mevets (322601) | more than 3 years ago | (#36092562)

I used to deplore meetings; listening to some preening jackass and thinking about how far we were getting behind by this. It isn't just the time sitting in the room, but depending on how bad it was, focus could be lost for the rest of the day.

Then I became freelance. Meetings took on a whole new significance. These jackasses paying my rate because I'm good at a few things; but rather than have me do those things, I'm sitting in a meeting, bored, but well paid.

Look at your contractors in the next meeting; if they aren't in the scapegoat chair, they are the only happy ones in the room.

Re:This is why I left development (3, Interesting)

Anrego (830717) | more than 3 years ago | (#36092638)

Maybe try a smaller company. Find a nice 5 to 7 person operation, bonus points if software isn't the main objective. When you are programmer 1 of 1, you find very little process, and what process there is, you define.

Two sides to everything (2)

Haedrian (1676506) | more than 3 years ago | (#36092292)

On one hand, I can understand the creative process that goes into coding and the 'fun' you have in making it your thing.

However if you're likely to have millions of people depending on your code, which will alwso be modified by other people, then you had better have a good process as well.

I used to work at a company which required that pretty much all the important pieces of code have JUnit tests for them. Whenever someone else touches your code - which is bound to happen (I was modifying code which was written years ago - and the author wasn't employed anymore), it'll be a good thing if you know you haven't smashed anything.

So there's a time and a place for everything. If its very important code, yes please, strictness. If its something small and silly, then go creative on it.

Re:Two sides to everything (1)

w_dragon (1802458) | more than 3 years ago | (#36092538)

Except all you actually know is that you haven't smashed anything in a manner they thought to test for. In my experience while unit tests do decrease obvious bugs, they also decrease real testing after developing a feature where the developer runs the feature a few times to verify it actually works.

Re:Two sides to everything (0)

Anonymous Coward | more than 3 years ago | (#36092800)

Too much process is good for people that don't know how to write good code. I've seem crappy people that could spend 100 hours on something make their code 5% better by spending 200 hours on it. I've seen good people

The problem here is generalizations. People (managers) immediately understand the difference between a good mechanic and bad mechanic. The good mechanic can fix things without manual, wuickly and efficiently. The bad mechanic needs manuals and screws up half of what they touch. But these same people (managers) don't understand that software is not much different.

Good code is self documenting making a design document pointless. Good knowledge of design patterns and cosnsistent use of naming conventions (Event, Listener, Thread, Decomposer, Composer, etc) makes up front design pointless so long as you have a willingness to refactor things. 90% of the code I write these days is simply covered by the model-view-controller pattern and no "top level" design is done.

Point is, a good software engineer is hampered, not aided by documentation. of course, I am probably making generalizations. If you are writing a big program, top level design is needed. But not for smaller ones. Interface Design Documents are equally pointless. I've seen to much time spent on those where they are never correct. having coders of two applications work together on a network API is better. That document should be a result of coding, not a result of some process.

And CMMI is one of the worse things ever to be created.

Beh (2)

Hognoxious (631665) | more than 3 years ago | (#36092298)

I've worked on projects where they had procedures as thick as a phone book, and it was still possible to write crap code. In fact, due to the incompetence of the person who wrote them , they sometimes pushed you into writing bad code.

On the other hand, some programmers produce good code, whether they're specifically ordered to or not.

Management should be the ones executin the process (1)

evanh (627108) | more than 3 years ago | (#36092308)

That about sums it up. If they're so keen on doing it their way, then they can do it!

Re:Management should be the ones executin the proc (1)

Bing Tsher E (943915) | more than 3 years ago | (#36092842)

That's fine, but what will you do with all your spare time without an income?

Mutual dislike between managers and coders (4, Insightful)

140Mandak262Jamuna (970587) | more than 3 years ago | (#36092312)

People who are passionate about coding, rarely make it to the management cadres, partly by choice, partly because they lack the other skills needed to be managers. So the management is filled with folks from sales, marketing and mediocre programmers.

I think may be the guru-disciple system of education practiced (allegedly) in ancient India might bear better fruits. Guru lead teams with disciples learning from them might turn out better quality code, but the system would be expensive in the short run and takes a while to take root. The quarterly bottom line obsessed corporate world is as far away from the system of stoic ascetic guru living in a hut in a jungle accepting princes as students romanticized in Indian mythology.

Re:Mutual dislike between managers and coders (4, Insightful)

tripleevenfall (1990004) | more than 3 years ago | (#36092414)

There's a lot of truth to what you say. I am one of those. I think I was a "B" grade coder. Not a star, but adequate. I developed the skill, met deadlines and specs. It just wasn't my calling like it is for some.

Frankly, I don't think it's bad to have somewhat mediocre programmers in your management structure. We understand at least a good chunk of what developers are doing, and when we don't you can explain it to us and get understanding. If I'm a McManager who used to be in HR and has never written code, I'm not going to understand your basic needs as an engineering team. You won't be able to explain to me why a certain architecture isn't workable. I understand you and what you need 80% of the time and I can go fight those battles and leave you to code.

I think it's good to have mediocre programmers become managers if they have the management skills necessary (and aren't simply promoted because everyone else is irreplacable). Most of the time those skills are not common to the skillset of the best developers. It's better to have average developers become good managers than having good developers moved out of programming and into management, leaving only mediocre programmers writing mediocre code.

Re:Mutual dislike between managers and coders (0)

Anonymous Coward | more than 3 years ago | (#36092832)

Totally agree! The best managers I've worked with are people who freely admit this.

It's the managers who think they got promoted because they were the star programmer, and use that as weight to push those under them to do things their way who give everyone a bad name.

The ones who have enough understanding to make decisions and oversee things at a higher level, but know their limits and let the programmers under them do their thing... they are golden!

Former managers from the "business side" can work too... if they can accept they will never fully understand what the people under them are talking about, and can work around it. Again, the trend here being that knowing your strengths and weaknesses tends to be the difference between "why the hell is this jackass incharge" and "he deals with that shit for us so we can just code".

Process (2, Interesting)

Anonymous Coward | more than 3 years ago | (#36092316)

Only about 10% of programmers are "artistes" who create new things of beauty...process stifles those.

80% of programmers come to work more-or-less on time, sit where they are assigned, work using the tools and processes given, and produce most of an organizations output. Process is beneficial to those, in that it makes their work useful in the overall "whole."

10% of programmers should be fired before they do any more damage. A better HR process would help with those.

Re:Process (3, Funny)

roman_mir (125474) | more than 3 years ago | (#36092474)

your comment is mostly wrong.

Only about 2% of programmers in a large company actually do most of the real work.

20% are good for chit chat.

78% should be fired immediately.

Different time, different place, different plan (1)

bytesex (112972) | more than 3 years ago | (#36092340)

The first version needs to written with passion. You then throw it away, and write the second version seriously. Also, code for your next php-driven social-thingy must be written with passion. Code for the satellite, not so much.

Re:Different time, different place, different plan (1)

Entrope (68843) | more than 3 years ago | (#36092422)

Don't confuse impetuosity with passion. I write code with non-trivial safety outcomes if it fails to do its job. I manage to do it with both process and passion. Sometimes I even surprise myself and have passion for the more tedious parts of the process, because I know they make the product better given a certain schedule: The systems I work on are complex, and even though I am a smart guy, I cannot keep all the details on all the systems and subsystems I have to work on in my head long enough to analyze designs and changes without following some processes.

Re:Different time, different place, different plan (1)

dkleinsc (563838) | more than 3 years ago | (#36092528)

Same here - I'm passionate about code reviews and unit tests. Seriously. Especially on the stuff I've written, but also for other people's code.

Unit testing is fun if you approach it with the right attitude: I'm going to explore a system and see how it behaves. Each test is a representation of the question "What should happen if I do this? What actually happens when I do it?" The first question is the joy of creating functional specs and design. The second question is the joy of experimenting.

I'm also passionate about code reviews because they're a fantastic teaching and discussion tool. You end up with conversations about "Why did you do things that way?" or "Have you thought about doing ..." which makes it easy to educate developers on approaches that others are doing.

Re:Different time, different place, different plan (1)

rwv (1636355) | more than 3 years ago | (#36092558)

Also, code for your next php-driven social-thingy must be written with passion. Code for the satellite, not so much.

I want to write a php-driven social-satellite. Should I be formal about my passion?

Or maybe I should switch from php to python.... import antigravity []

TDD (1, Insightful)

Anonymous Coward | more than 3 years ago | (#36092364)

"We all know by now that Test Driven Development is a best practice."

No, TDD is a painful waste of time that at best serves as a crutch for unskilled or insecure coders and at worst a smokescreen behind which serious bugs remain unfixed because they aren't picked up by any test cases.

Re:TDD (4, Insightful)

tigre (178245) | more than 3 years ago | (#36092694)

TDD is a painful waste of time that at best serves as a crutch for unskilled or insecure coders and at worst a smokescreen behind which serious bugs remain unfixed because they aren't picked up by any test cases.

No, TDD is painful, but it's a long-term investment. If you code once and never have to touch it again, you can get away with making it work right without tests. But if you want to be able to grow your system, you want something to make sure that you don't kill the old functionality in the process of building the new. And sometimes it's just helpful to spell out the expectations of new functionality ahead of time so that you know when you've achieved it.

Process for the sake of process is pointless. And if you have good reason to work around or jettison a given process, go for it. As I told the other programmers at my job, the only piece of our process we would probably consider an absolute necessity is source control. Code review is highly recommended, tests are very strongly pushed, formatting standards are there for good reasons, but there are times when they are not helpful.

The problem always comes down to whether or not your developers are adults with good decision-making capabilities. Process is too often employed as a way to allow you to get stuff done with people of average or less ability, but process also hurts them because they can't figure out when the process is unhelpful. And if process is imposed by fiat, those who could figure that out are frustrated by having to go through the motions. But if you have trustworthy people and you actually trust them, you institute the process for their benefit, and when it's not useful they know not to use it.

Measuring Code (3, Insightful)

rwv (1636355) | more than 3 years ago | (#36092366)

The main issue is that measuring whether code is good or not is impossible. I promise you that I can write code that has the prescribed level of unit testing and complexity that also doesn't work. Software reliability/dependability was a problem in the 1960s. It's still a problem today. No silver bullet, and all that.

Inappropriate reliance on process... (2)

shic (309152) | more than 3 years ago | (#36092386)

What really cripples things is when process is deemed a substitute for understanding the specifics of individual situations - where a one-size-fits-all-problems approach is adopted and imposed - usually by people who have no practical experience with the processes they espouse.

If software development could be successfully reduced to a process, I'd have automated it. Where there's a considerable burden of process, either the process is inappropriate - or developing the software itself is inappropriate as it amounts merely to re-inventing the wheel... an exercise in task creation that benefits no-one.

We should think of software development techniques and apply them judiciously - and the more techniques a developer masters, the wider their skill-set and the better they will adapt to new challenges. The critical question that needs to be asked is this: why is a technique being used and is it providing tangible benefits? If this question can't be adequately answered, everyone involved is wasting their time.

Re:Inappropriate reliance on process... (1)

gbjbaanb (229885) | more than 3 years ago | (#36092468)

you got that right - I think most of these 'best practices' are more fashionable things rather than ways to achieve excellence.

I've been writing software for some time, and I used to write code well before TDD was invented. My codeworked back then, so why would I need TDD now? Sometimes I think maybe its because the tools and development practices are geared towards that - we do a lot of fast-development methods whereas once upon a time we'd take time to do design and validation before getting stuck in. Today it seems getting stuck in is the first and only thing, so I'm not surprised we need TDD to fix that, and that leads me to wonder if the time spent writing tests makes the fast-dev cycles so much slower that you might as well be faster overall doing it the old-fashioned ways!

I know we have started doing some of these things, not because the code is bad and needs fixing,but because someone read about it on the internet and thought that we shoudl do it because everyone else is doing it - ie, entirely due to fashion.

Re:Inappropriate reliance on process... (1)

MonkeyRobo (1925130) | more than 3 years ago | (#36092488)

Quite. Having a process is not, and can never be, a problem. Having a bad process is a problem. If your process involves regular retrospectives, where everybody can contribute to making things better, then your process should tune itself over time. (Well, assuming you are empowered to change things for the better, that is.)

Darth Vader, bring balance to the force (1)

laffer1 (701823) | more than 3 years ago | (#36092398)

There is a balance between process and actually getting things done. Most companies never find it. The biggest problem I have is when this is used to audit progress on a task. For instance, I am a consultant for a company just starting to get out of startup mentality. There's been a push for more process and they've implemented their version of Agile. One of my first tasks was to write a script to dump data from Agile Zen so they could run reports on how fast developers are finishing stories.

Fail #1: All stores are not the same size!
Fail #2: Each team has different rules for stories and use agile zen differently. How do you compare them?
Fail #3: About half my time is spent in meetings, writing stories, fighting with QA to test things (not enough people). I'm supposed to do the same amount of work in half the time? ...
Fail #n: You're doing it wrong

The worst part is that when we had PRDs, at least there was a big picture loosely discussed. Now we get stories that don't integrate with each other and a big ugly mess.

Re:Darth Vader, bring balance to the force (2)

Spy der Mann (805235) | more than 3 years ago | (#36092748)

I completely agree. I've come to believe that Agile development is a fad invented by some marketing genius to get big loads of buck from gullible enterprises. While TDD might be useful for, say... a linux kernel module, there's very little use for it in your standard "make me a module which reports in detail our budget surplus and deficits" project.

It's much more efficient to hire a small team of beta-testers available on-demand ("Jim wrote this new model, can you test it please?") than wasting hundreds of man hours per-month in "agile" development.

Unit testing the unit tests? (0)

Anonymous Coward | more than 3 years ago | (#36092408)

How do we know that someone has written good code in the unit tests? The cycle goes on and on and in my opinion if you're not asking for help WHILE you are doing you work on an unknown system then you are deeply flawed as a programmer. You should be seeking advice before hand and during your coding, this is an even cheaper point to make changes than even a code review. Why are you having-a-go and then finding out you've done it wrong because you didn't ask the code owner how he thinks it should be done.

Passion isn't important (2)

Uruk (4907) | more than 3 years ago | (#36092412)

Passion isn't important. Cost and risk are important. The processes are put in place to (attempt) to minimize cost and risk associated with software development. Experience teaches us that cost and risk are very high when building software.

When it's your money paying for the development effort, feel free to structure it so that you can chase your passion.

I sympathize with the idea that this kind of bureaucracy can suck the life out of developers, but guys, this is work. If it were that fun, they wouldn't have to pay you to do it.

Re:Passion isn't important (2)

Entrope (68843) | more than 3 years ago | (#36092478)

People who have passion about what they are doing are usually much more productive than people who view the job as a way to get a paycheck. They also tend to want to stay longer, meaning the organization saves on replacement and retraining costs. There are also just wrong processes (of which "too much process" is a case) for an organization, so organizations need to do cost/benefit analyses on their processes.

Other than that, I agree with you. Developers have three choices when they are faced with a process requirement that annoys them. From easiest to hardest: (a) suck it up and do it because it's part of the job, (b) quit and look for greener pastures or (c) try to convince the right people to revise the process. (Sometimes (c) is easier than (b) if the process is new, and the cumulative effects of (a) can make (b) easier when summed over many annoying process requirements.)

Re:Passion isn't important (3, Insightful)

Derkec (463377) | more than 3 years ago | (#36092768)

I firmly disagree. Passion is key. People who don't give a damn and people who don't enjoy coding tend to write crap. We try to hire for passion and smarts (knowing both are hard to interview for).

Passionate people given good processes and tools are ideal.

Yes, for proprietary software. (1)

VortexCortex (1117377) | more than 3 years ago | (#36092440)

As more and more DRM "solutions" are deployed, and the DRM systems themselves get larger, more complex, and more expensive, I think you'll find it not far from the truth that: "Process killing" IS the Software Industry.

Only individuals can be passionate (1)

joh (27088) | more than 3 years ago | (#36092444)

And most software is not written by one individual.

As soon as you have an actual team writing software and as soon as there are others telling this team what they have to code, you need every bit of control you can get. There's no way around that and every anecdote "proving" you can get away with passion and good coders just proves that you can be lucky.

Devs should own the process (3, Insightful)

Derkec (463377) | more than 3 years ago | (#36092452)

This is really the key insight of most Agile methodologies. Development should own the process and change it to suit their needs during regular retrospectives. The team (not the whining individual) should be able to say, "You know what, I think we're not getting bang for our buck out of this many unit tests, let's shift to 50% coverage." As long as that same team is taking ownership of the regression failures and making an informed trade-off their comfortable with, all is well.

If you get a good team together, you're going to get good code. You'll get better code if you empower them. Experienced and good teams will usually have a lot of these processes and tools in place because noticing things like high code complexity automagically alerts them to "bad smells" that can be examined and either accepted as necessary or invested in to address or test more thouroughly.

Generally, I think development is most fun when you're on a new project and don't give a damn about breaking things. Then it's pure creation. But once an app is older and there's some weird code you're staring at you have to decide, "is this probably a bug, or is this a bug fix for some weird situation or platform?" That's when you wish that the guy having fun three years ago had written some damn tests.

Re:Devs should own the process (1)

gbjbaanb (229885) | more than 3 years ago | (#36092524)

That's when you wish that the guy having fun three years ago had written some damn tests.

But today, the guy who writes the tests (and hopefully keeps them updated) is the same one who agrees with the "my code is its own documentation" principle and doesn't put a single comment in there. He won;t have written the design specification either, or the install guide so you still won't know how the damn things works.

There's no silver bullet for doing things right, TDD isn't any different. Good devs can tell bad code from looking at it, they don't need CCN reports to highlight it, and as someone else said - I can write code that passes all unit test coverage requirements and still doesn't actually work.

You're quite right about the difference between new code and maintenance - sometimes I think the onyl answer to it all is to put the 'rockstar' coders on maintenance duties and let the old sloggers work on the cool new stuff. Too bad things are often the other way round!

Cue whining here (0)

Anonymous Coward | more than 3 years ago | (#36092494)

Yet another one-sided argument from a singular viewpoint which the author thinks would solve his or her problem in the real world. "Process makes me unhappy; find article, post Slashdot, ???, profit!" Ill-implemented process may cause undue headaches, but, unless I miss my guess, no work environment is perfect out the gate. Your willingness (and the willingness of the people around you) to adapt and change process to adapt to the varying people and personalities in your organization is a measure of quality in the workplace.

While I'm here, I may as well mention that coding is hard, debugging is hard, typing is hard, I wish my computer would just understand me the first time, I wish I could simply live in a tropical locale and "work" from the beach, and I wish I didn't have to really do anything "hard" to earn my salary. Now let me see if I can find some articles on those topics...

This is idiotic (0)

Anonymous Coward | more than 3 years ago | (#36092500)

I’m so damn tired of people over analyzing the software development cycle. It goes against one of the basic tenants of computer science: Keep It Simple Stupid.
To write good software one does the following:

Write code
Test code
Fix code
Ship code

If you aren’t doing one or more of those things, then you’re a useless pile and you need another job in another industry.

competition (1)

roman_mir (125474) | more than 3 years ago | (#36092526)

Like in everything else, from economics, to love life (whatever it means for different people), there needs to be competition in software development. This means performance based compensation, this also means getting rid of those, who cannot achieve.

Developers should get goals in terms of business questions, then they should be let to do their own estimates and they should 'bid' on projects. There should be tracking of the success of different projects - from accuracy of estimate time and cost to number of features, to number of bugs per unit of time, to overall user satisfaction, to amount of time it takes to fix a bug or add a feature (this really would measure complexity and cleanliness of the code), to the average amount of time it takes the support team to deal with user issues (cleanness and usefulness of documentation.)

It is possible to do this, of-course large organizations rarely if ever achieve this level of 'enlightenment' even to start thinking about things this way, that's mostly because people do not understand economics, it's not about software.

Not the problem (2)

asherlev (2499) | more than 3 years ago | (#36092542)

Process isn't the problem, environment isn't the problem, language isn't the problem. The problem is that everyone looks to all of these things as the silver bullet that's going to "fix" software. Test driven development doesn't make good software any more than I-495 makes New York City. There is no silver bullet. []

Welcome To Engineering (0)

Anonymous Coward | more than 3 years ago | (#36092552)

A large portion of code goes into devices that control extremely powerful technology that can easily kill a lot of people and/or do massive damage to other systems which can get very expensive. Testing and validation is the core of the engineering world and code is very much a part of that now (and becoming more so each day that more large systems are computer-controlled).

I recommend this book:

The sections about the Mars lander screw-ups (code-based) are very pertinent to what happens when the slightest piece of code does something wrong or unexpected. Bad code can easily result in a chain reaction that concludes in a major disaster.

Distortion: construction is free (4, Insightful)

dazedNconfuzed (154242) | more than 3 years ago | (#36092560)

In most engineering disciplines, the process of actually building something is long, hard, expensive, and persistent. If the project is build a bridge, you spend a lot of time making sure the design is right; why? because the process of actually building the bridge takes months or years, costs many millions of dollars, and once built is not easily replaced. There is no room for error, so process is taken very seriously as a central part of ensuring timely cost-effective correctness.

In software, the process of actually building something is instant, easy, free, and transient. Type "make all" and go get some coffee; find a bug? tweak a couple lines and do it again. This distorts the development process; "process" gets snubbed as a costly distracting annoyance instead of the means of assuring that what gets delivered is correct, because it's just so dang easy to fix and rebuild in seconds ... losing sight of the long-term cost of not doing it right the first time.

Re:Distortion: construction is free (4, Insightful)

Tridus (79566) | more than 3 years ago | (#36092736)

A bridge is also a fixed, well-known thing. It's not going to change radically in design between when you start and when you finish building it.

Software on the other hand is written for customers who themselves don't know what they want, in a market that is probably rapidly changing. It WILL change between the start and the end of the project in a lot of cases. Sometimes it changes because the customer changes their mind. Sometimes it changes because the market changes. Sometimes laws change. Sometimes the customers were just flat out wrong in everything they told you and the entire design is wrong as a reuslt.

When you're dealing with that, process does just get in the way.

s/w dev != manufacturing (1)

sridharo (1433649) | more than 3 years ago | (#36092572)

Processes are defined in the manufacturing industries to prevent slippage of 'achievable/defined' quality. Unfortunately the extension of processes from these industries (six sigma?) to software development doesnt reap the intended benefits.
Blame it on the guy who thought the role of a programmer and the line technician are the same!

Is it work or process? (0)

Anonymous Coward | more than 3 years ago | (#36092586)

TDD is coding not process. Grooming is requirements elaboration and design, essential work that engaged developers appreciate being part of (as opposed to being fed technical tasks as if they were automatons). CCN is just a measure of easy to maintain code and good design, not process. Doing some pairing on the hard parts solves reviews. While I agree that many orgs kill developers with process overhead, your examples are not the offensive parts, rather the essential parts.

fun and games until the revenue stops coming in (1)

alen (225700) | more than 3 years ago | (#36092592)

i've seen supposedly passionate coding in practice. good people but it's almost impossible to work with them since they social outcasts.

a software release turns into a 4 hour nightmare because everything worked on their dev laptop but in the real world it doesn't work and they have to figure it out. but they don't give you all the information and you have to wait on the phone at night while they tinker and fix it in production. meanwhile employees can't take customer trouble tickets.

or the billing system can't make customer bills because it's now multi-threaded but there is no system to control which bills are processed when and the different threads lock each other out in the database because some selects lock down most of the table. yet the code is good and can't be changed

Cholesterol (2)

geoffrobinson (109879) | more than 3 years ago | (#36092594)

A wise elder at a defense contractor once told me that process was like cholesterol. You can't have none. But too much will kill you.

True. (0)

Anonymous Coward | more than 3 years ago | (#36092620)

Creativity passion and, I add, freedom are dead. Not only in programming, have you seen a Hollywhood movie lately?

It's all about disaffection, process, workarounds and hacks to avoid the process, plus some people forcing some other people to make things every day more overkill, making them in turn more disaffected, unpassionate and happy to go home at 5:00 PM sharp.

Nonetheless which remains the most used OS in the world?
I'll give you a hint: its name begins with the contrary of "lose". And it's not exactly a "creative" product.

Detroit: Where the weak are killed and eaten. (1)

bshensky (110723) | more than 3 years ago | (#36092640)

While all you process-laden geeks with your SCRUM teams and unit tests are getting the life sucked out of you in the Valley, we here in Automation Alley live by the seat of our pants, Montgomery-Scott-style, delivering barely-passable code on time, with the enhancements and 80/20 fixes to be pushed ahead of next year's model refresh, and a keen eye on the Bugzilla board, waiting for our user community to serve up the bug list. Thrilling, I tell ya.

Didn't yo mama ever tell you not to buy a first-year model?

I just wanna have fun (1)

SlashRdr (557811) | more than 3 years ago | (#36092652)

Of course doing everything to an extreme isn't a cost effective way of working. If he has his way the other developers on his team would leave or kill themselves: "But, for example, maybe junior (or specialized) developers should be writing the unit tests, leaving the more seasoned developers free to concentrate on the actual implementation of the application.". Sounds a little arrogant to me.

Coming soon to a dev team near you... (1)

Enter the Shoggoth (1362079) | more than 3 years ago | (#36092670)

Are you finding the majority of your code is actually made up of unit tests?
How can you be confident that your tested code is safe when delivered into the clients hands?

Introducing Meta-Test(tm) - with this breakthrough in software engineering methodology your drones can increase their coverage numbers without writing a single extra line of application code!!!!

Hurry! Don't miss your spot at our upcoming seminar where you will receive details on how to send your drones to our new training sessions that you can bill back to your clients and put your project even further behind schedule!!!

discipline & partners (1)

achowe (829564) | more than 3 years ago | (#36092678)

I've always been passionate about my code and attempt to test as much of it as possible, but I've found what saves on testing / process is discipline in coding style, commenting, consistent use of language idioms, good function / variable names, checking all function returns, lots of debug logging... Lots of little things that a programmer can do to help them read and diagnose their code during development and testing. It also helps to work with a "testing" partner (an element of Extreme Programming). I don't formally follow Extreme, but I do know from experience working in pairs or on occasion threes works really well: let the passionate go nuts with the support of a tester who should be equally passionate about that aspect of code (it is possible to find), and maybe the third is simply a mentor to overview and act as a sounding board for design ideas and problem solving. My partner and I will often discuss and compare ideas again and again; I'll code something, test it, then pass it to him to test it in depth. In many ways it becomes a game to write the code clean and for him to fault it. []

I like reading good code. (1)

drolli (522659) | more than 3 years ago | (#36092690)

And i love programmers how manage to encapsulate good ideas in a way that they are not harmful.

Look at government for process gone amok (1)

Tridus (79566) | more than 3 years ago | (#36092710)

If you want to see what happens when you keep layering more process on to try and fix perceived problems, just take a look at how any bureaucracy makes decisions. Government is well known for doing things that don't make any sense in the real world, and the reason why is that our (I work for a government) decision making isn't based on reality. Or even decision making, for that matter. It's all based on following a process and doing whatever comes out at the end. With enough process and a process-focused group of managers, the results don't even matter. Literally, this is the way people think: "Whatever happens has to be right because we followed the process, and if it goes wrong it's not our fault because we followed the process!"

There's always going to be some level of organization and control that is needed when several people are working on a common project, but you have to balance that with the need for people to actually think. When you pile up process on process on process you remove that and instead get a bunch of people who can't see what's actually going on because they're too busy complying with 14 different processes.

This particularly applies to software development. It's really important for a team to pick out what they specifically need for their project and what works for the team. Throwing in something like (for example) Test Driven Development just because it's currently a buzzword-compliant process won't get you anything except a lot of wasted time. Sadly, bad managers love to do exactly that because adding more process is itself a good CYA (Cover Your Ass) process.

Methodology == Religion (2)

syousef (465911) | more than 3 years ago | (#36092712)

The real problem is that methodologies are followed, taught and practiced like religion instead of science. A new buzzword or buzzphrase and a new way of doing things will never substitute for thinking through whether what you're doing is actually working to attain the goal you've set out. Unit tests for example are brilliant when the developer gets control and is honest about using them. This almost never happens in practice. In practice unit test coverage becomes some bureaucratic check box to tick. What's worse is that there are dozens of industry expert consultancies wanting to sell you their own particular brand of excrement which may have some merit but the way it's sold - as a fix all for everything - will never be anything but a pile of poo.

Passion (1)

SwashbucklingCowboy (727629) | more than 3 years ago | (#36092728)

Depends on what the software is doing. If it's controlling my car or my mom's pacemaker I want the developers having a passion for making sure the code is 100% correct.

"process" should help focus competence but (1)

a2wflc (705508) | more than 3 years ago | (#36092756)

Too often "process" and tools are used as a substitute for competence. It's VERY easy to follow process and design patterns and use all the latest tools and end up with a brittle design & implementation. It's also easy to create a very similar design/implementation that's is robust and extensible and easy to maintain. And 90% of the people I've worked with over the last 10-12 years wouldn't be able to look at them and determine which is better (they'd most likely say the first is better if they were told the name of the methodology and design patterns used). After a year where the first fails repeatedly (crashes, can't meet new feature deadlines, etc) and the 2nd has been a huge success, they couldn't tell you why.

Use it wisely (0)

Anonymous Coward | more than 3 years ago | (#36092758)

Excessive process may limit creativity. But lack of it may as well kill creativity in a moment. Process is like a contract. It doesn't only impose an obligation on a developer. It also protects developer.

You may get very tired very fast by rapidly changing requirements if you don't have sprints. In the middle of day your manager comes by you and says that you have to throw away 300 lines of code because your client want entirely different thing now. And if that happens three times a week by the end of month you just blankly stare at /. and youtube half a day because by that time you may know if new requirement are arriving or you can do that damn thing by the end of the day.

If you don't have any tests on a project and have more than one developer you may very fast get tired fixing same bugs over and over again.

I mean, all these best practices can be a good thing if they practiced wisely. Anything can do harm if used in excess. You can even poison yourself with pure water if you drink it a lot.

From the other hand some process can leave some time for devs to tackle their ideas in a branch. Say, implement some cool feature that was not in any user story. The prototype can be evaluated and scheduled for next sprint to get its user story, test, documentation and polish. Enthusiasm can not be planned. And most of the creative code I've seen was written without "test first" or deeply thought through user story. That's what 20% at Google (and all the similar programs) do. They codify creative fork. Also 20% is a process too.

In contrast to reliable software (0)

Anonymous Coward | more than 3 years ago | (#36092760)

How often does software crash? well, less today than in yester years... but... let's contrast this to the software written for NASA systems... IIRC, 1 crash in the last 10 years?... and you damn well bet they have process.

An article I'd read (can't find the link) indicated that almost every line of code is already in spec (as pseudo-code), and approved... if it's not in spec and approved, it doesn't get in... does that make the process boring? perhaps, but the result is unmatched by any other software.

A agree (0)

Anonymous Coward | more than 3 years ago | (#36092766)

I can not say more then, I agree... Processes are killing my mood to code, and that produced less code, and less quality of the code.

Need moar people (0)

bytesex (112972) | more than 3 years ago | (#36092796)

Test Driven Development is fine, so long as *you* (the coder) isn't the one writing and performing the tests. Testing against yourself is a useless waste of time.

Developers (1)

mbrod (19122) | more than 3 years ago | (#36092806)

The creativity should come from Designers now. Developers just implement the design. It is the Designers that need the passion, Developers don't have that role anymore.

Chase the coverage (0)

Anonymous Coward | more than 3 years ago | (#36092824)

Its quite managers ideas to put any metrics in what you are doing, since software development is an industry already, not only some geeky stuff... That's not a bat practice actually... This will help establish estimations, count risks etc.
But sometimes gathering this statistics or assuring them to be gathered can be of significant overhead. For example to provide the required metrics I was forced to write junit tests for simple enums...

So I think this is a question of the correct approach to current situation. If it is 777 you really need it, but if it is a small webapp that's just waste of time an money...
Always talk to your manager.. or you client. Remember the rule: cost, speed, quality - choose two...

Regarding unit tests... (1)

jcr (53032) | more than 3 years ago | (#36092850)

I know that one particular development group at Apple found considerable gains in productivity from using unit tests consistently, where every time they fixed a bug, they wrote a test to confirm the fix. The upshot was that they spent far less time chasing down regressions than they did before they adopted the policy.


Load More Comments
Slashdot Login

Need an Account?

Forgot your password?