Is Process Killing the Software Industry? 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.'"
"Creative" (Score:5, Insightful)
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" (Score:5, Insightful)
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" (Score:5, Insightful)
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" (Score:5, Insightful)
And the certifications don't actually check any code, they just check that the processes chosen are the right ones, and can even miss if the processes don't get adhered to. Perfectly developed and certified software can still have a ton of bugs that will crash that 777 or shut off the heart monitor in a hospital.
Less on process and more on coder competency would help. Pick the best coders and double their pay.
Re:"Creative" (Score:4, Informative)
These days I work in a company that's been CMMI level 3 certified for years and we have a process in place for each level of necessity; light, medium, heavy, manned-flight. All of our requirements are part of the contract, before any design even begins, and if they change the customer must pay for the change. It's a joy and my creativity is unleashed, not restrained.
Process is not your enemy. It's the lack of buyin. Everyone must participate and ensure the process is held. Requirements definition is part of process and if you don't have stable requirements, you aint got shit.
Again, I love working within our process, whether it's the light one or the manned-flight one. It's well defined and provides a schedule, but doesn't tell me how to write my design/code/test, just that I get it reviewed at all of the proper phases.
Re: (Score:3)
For most projects you will never have all the requirements defined up front.
Writing detailed complete requirements takes about as long as writing code, and as you've mentioned clients usually don't know what they need.
So the developers/analysts will have to write the requirements for them and guess what they want and how they might change their mind in the future. How much they guess wrong depends on luck and experience ;).
I've put in stuff before which people say they don't want, but later they want/need it because of some new external demand.
If you get the foundation/schema/design right, you don't have to rewrite stuff to add features they want later. You don't have to write all the code in advance, just prepare the way "just in case" :).
One of the big pains I find is fixing/overhauling other people's code. I'm far from a great coder, but often it seems the reason other developers seem so fast is because they're skipping a lot of stuff, or even doing things plain wrong. The other big pain is dealing with crap like "legacy PHP" and similar crap that make it so hard to do stuff the right way.
FWIW, some people have had decent results writing the "user manuals" first! I see some merit with that idea, but I'm not sure what projects will be good with that approach.
The thing is, the developers have to write the requirements anyway. You can either make it explicit and write a document up front, or you can do it piecemeal as you go along, which will lead to constant errors and backtracking. So you might as well do it up front.
I'm writing a document right now (which wasn't requested by managment, BTW) just so I could nail down all the points so they can't come back later and say "that's not what I expected".
Re: (Score:2)
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
Re: (Score:2)
there not their*2
god I need to sleep more.
Re:"Creative" (Score:5, Interesting)
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" (Score:5, Insightful)
Was gonna mod you up, but instead, it hit me. The problem isn't the process, it is where the process is engaged. And I think the Article and subsequent posts clearly indicate there is a time and place for process, but not everything needs to be stuck in a process.
In your case, you and your team were building tools for your own use and were doing it the quick and agile way. Dirty code that got stuff done quickly. You bypassed the systemic processes that were in place because they just got in the way.
The successful code base often starts out as UGLY spaghetti code, but eventually needs to be cleaned up.
What needs happen is your skunkworks program should be autonomous from the normal process. Only when something you've created gets noticed does it move from the skunkworks over to the normal development channel. To accomplish this, you have to be willing to hand off your code to someone who is, more than likely, going to "ruin" it by running it through the process of getting it clean and neat.
This way, you can still build fast efficient code that is messy and ugly, and the managment can get code that is functional, and everyone can work towards getting it all nice and pretty by process. Everyone wins.
Just my thought
Re: (Score:3)
"In your case, you and your team were building tools for your own use and were doing it the quick and agile way. Dirty code that got stuff done quickly."
This kind of thinking is exactly the problem. There is no reason "agile" code has to be "dirty" code. Studies have shown that it can be of as good or better quality than code done "the other way". But management resists that, because... they think like you: if they are not dictating the process, it isn't going to get done "right".
Re: (Score:3)
This is why things like "Google Labs" exist, in my opinion. Just imagine if every company had a formal "Labs" entity within IS/IT. The only problem is that being able to have a free-flowing anything goes R&D-type department (which is separate from your ordinary every-day "structured" or process-based type department) usually requires corporate support, a company of a certain size, enough people, or enough discipline to separate R&D time from planned/organized/structured time.
I believe the core pur
Re: (Score:3)
"There are three things you can pick: Fast, Cheap, Tested"
If done right, TDD can be faster than other development methods. Why? Because, among other things, it eliminates having to go back and fix regression bugs and other such issues, which standard "after the fact" testing does not address.
And at the same time, it actually reduces the time, size, and budget needed for traditional "after the fact" testing and QA.
Re: (Score:2, Interesting)
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
Re: (Score:3)
Re:"Creative" (Score:5, Insightful)
I rated you up, but I notice that most people seem to be missing the most important part of your post.
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.
I agree that software development can be 'over-processed'. And I think that management frequently decides to 'apply more process!' in lieu of actually carefully thinking through what would help. But usually, when developers complain about process and delivering things on time, I think "Oh, so you just want to slap that code in there without even really knowing if it works. Write code, compile, problem solved!". Good process is what keeps you on-track and disciplined to write quality software. Too much software in our industry is of extremely poor quality, and that's still the case. Developers should feel proud of writing software that works, not how much software they write.
Most of the responses I see to your post seem to be of the "You're darn right, all that process just kills development!" variety. No talking about how to balance things for quality results or anything of that nature. I'm kind of disappointed.
Re:"Creative" (Score:4, Interesting)
I am disappointed too. I have lost count of the times that my coworkers (or direct reports) decided to skip documenting a design because of pressure to get the code done, only to have that come back and bite them (and the project manager who was applying the schedule pressure) later. Then there is one coworker who made commits to reindent and reformat every source file in a project -- mixing that with functional changes. Another coworker decided to write his own not-quite-XML parser.
I probably annoy my coworkers occasionally with my insistence that we define and follow certain (usually minimal) processes. I know there are one or two people who hate our code review system. However, I have never advocated for a new process unless it was meant to fix a recurring problem and I thought it was close to the most efficient way we could mitigate the problem.
Re: (Score:3)
I came to the conclusion awhile ago that making money is the wrong goal. The money should be treated as a reward, a signal that people think you're doing a good job, not as the goal. If you're treating it as the goal, you will do all kinds of things to get there that actually make things worse for everybody rather than better.
Re: (Score:3)
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
This.
People who blame process are like people who blame XML, or C++, or any other tool.
The problem is not the tool. The problem is the stupidity of the people who insist on using it in inappropriate ways.
Process is never the problem. Stupidity is the problem, which leads to inappropriate processes, poor metrics and bad management.
People who complain that "process kills creativity" are just as stupid as people who implement inappropriate processes. Ironically, they lack the creativity to see how appropria
Re: (Score:2)
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
Re: (Score:2)
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 ea
Re:"Creative" (Score:4, Insightful)
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: (Score:3)
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: (Score:2)
Re:"Creative" (Score:4)
He writes about creativity. You write about engineering.
There are now a multi-tude of disciplines in software development, yet this isn't very well understood.
I agree that the "management squeezing the life out of their dev-teams to make deadlines" with their charts, while devs are filling out sheets like monkeys to justify the space they take up, then it is absolutely a process that is killing.
I remember a time filling out 3 timesheets for the same work, filling out a scrumlog, doing a scrum-board, sitting in meetings, linking my code-check-ins with my timesheet. Management could make pretty graphs, but I wrote 20% of the code I did before. And it didn't work. All this overhead work is also not "estimated into the planning", so pressure mounts, creativity and production lowers.
Maybe the ad-hoc wont keep the 777 in the air, your papertrail and logs wont even get the software to be installed into your 777 and it'll never lift off. But it justified the bill presented for all the hypothetical work done (spent on filling in "justification files")
Re: (Score:3)
Right. And maybe 1% of developers out there write code that is that critical. *Maybe* 1%. Most are writing web sites or internal applications that have nowhere near that kind of criticality.
Re: (Score:3)
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.
I just finished an intensive course on Human Computer Interface (HCI) design. True, poor code can cause these things to happen - but so can poor design. In your example, we read a research paper where they discovered pilots use spacial location and position of analog instruments and components to gain information "at a glance", but with an all digital design they received information in purely numerical means and thus were unable to quickly process the information (in other words, the cognitive load of th
Re:"Creative" (Score:4, Insightful)
...and you've exposed the secret - developers can create and deliver good code WITHOUT being audited to death. The whole "lean six-sigma/ITIL/insert-the-name-of-your-favorite-process-methodology-here" is just another way for bean-counters and MBAs to pretend they can do something to add value to an endeavor.
Re: (Score:3)
I use lib777, so my code looks like:
while(!wantToLand)
my777.StayUp();
my777.Land();
There is no crash in the code.
Does anyone know the Happy Medium? (Score:4, Insightful)
Re: (Score:3)
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? (Score:5, Interesting)
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: (Score:3)
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
Re: (Score:3)
Brooks - and also The Pragmatic Programmer.
Agreed. Read both. Fire people who do not or can not understand it.
Budget (Score:5, Insightful)
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.
Re: (Score:3)
Serisouly if that is the case for you you must either be a genius (the unit tests are for nothing and don't ever reveal anything) or you do really a lot of stuff wrong.
Having >80% code coverage ashould cost less than 10% of the developmen time.
And having the unit tests should save over the whole team a lot of time as it
Re:Budget (Score:5, Interesting)
80% code coverage costing less than 10% development time? Only if you're either ignoring all errors, or have massive try catch blocks that catch everything generically (which means your code coverage numbers are garbage- if you aren't testing each way of generating each type of error, you only have a fraction of that coverage).
I'm not going to deny the usefulness of unit tests, but in my experience writing a good unit test suite takes 50-200% of the time to code the function, depending on the complexity of the code being tested.
Over my head (Score:2)
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 (Score:5, Informative)
70% Unit Coverage:
-- You've written code level tests that flex 70% of your code checking for regression failures.
CCN:
-- 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: (Score:2)
Re: (Score:2)
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: (Score:2, Redundant)
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.
[imho]
Cover
In a nutshell (Score:2)
Re: (Score:3, Insightful)
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 a
The solution is simple... (Score:2, Funny)
Get rid of management!
The one process to rule them all (Score:5, Insightful)
Re: (Score:2)
I'm passionate about programming, but not enough to have sex with my mother. I guess I'll never be a programming motherfucker.
Re: (Score:3)
My son's mother would work quite well for me.
This is why I left development (Score:5, Interesting)
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: (Score:2)
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: (Score:2)
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 (Score:5, Informative)
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 (Score:4, Interesting)
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.
Re: (Score:3)
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.
Something I've never understood, even after being in the game for three decades this year, is the proprietary field demands the majority of your time be spent doing all manner of foolishness. In the open source field, the programmers pretty much program 100% of the time they're "working". And the market has shown that any serious OS project absolutely crushes any proprietary project in reliability, featureset, security, documentation (At least in the internet / google / blogs / mailing list era).
Even the
Re: (Score:3)
http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html [ted.com]
There is also a mention somewhere that a core lib of Amiga os was written by one guy over 2 days in virtual isolation. He only had to get one design issue clarified with a superior during the process.
Two sides to everything (Score:3)
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: (Score:2)
Beh (Score:3)
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.
Mutual dislike between managers and coders (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Process (Score:2, Interesting)
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 (Score:4, Funny)
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.
Re:Process (Score:4, Interesting)
Different time, different place, different plan (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 passi
Re: (Score:2)
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 [xkcd.com]
Measuring Code (Score:4, Insightful)
Inappropriate reliance on process... (Score:3)
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: (Score:2)
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. Tod
Darth Vader, bring balance to the force (Score:2)
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: A
Re: (Score:3)
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
Passion isn't important (Score:3)
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: (Score:3)
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 proc
Re:Passion isn't important (Score:4, Funny)
I work in engineering, not software, still, the last time I encountered a passionate IT employee, he got fired for taking long, passionate lunches at the hotel down the street with an electrical engineer and fixing their timesheets to cover up their absence.
On a more serious note, you don't have to choose between passion and apathy. I'll take conscientiousness over passion any work day. Passion can at times be dangerous to objective thinking, partner relations, or a professional standard of care.
Re:Passion isn't important (Score:4, Insightful)
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.
Re:Passion isn't important (Score:5, Insightful)
And if you kill the passion, your cost (of hiring new developers because you drove the old ones away) and risk (of losing corporate knowledge in process) increases. So you can say "my money, my rules" all you like, but actually, it's reality that dictates the rules. And reality says if you burden people under a weight of bureaucracy disproportionate to what that bureaucracy is intended to accomplish, they'll leave. And if they don't leave, they're probably afraid of not finding another job, indicating that they're not good enough at their job to be confident in their abilities.
Like pretty much everything, it's a balancing act. You need to provide direction, or the goose is going to go wandering around the yard instead of laying its damn eggs, but if you stifle it too much, the thing's going to croak.
Yes, for proprietary software. (Score:2)
Only individuals can be passionate (Score:2)
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 (Score:4, Insightful)
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: (Score:2)
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 c
competition (Score:2)
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
Not the problem (Score:2)
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. [virtualschool.edu]
Distortion: construction is free (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Re:Distortion: construction is free (Score:5, Insightful)
" It's not going to change radically in design between when you start and when you finish building it."
not true.
In the process things gt changed, but it's part of the process. This includes new features added while building.
You don't see it becasue:
A) engineers can attach real world costs to any change and need to get someone to sign off on the costs.
B) You don't build bridges, so you don't see any development issues.
Properly engineered code would mean when a change comes up, you say 'it will take this long, and cost this much'. PLease sign the document stating this. You make the sign off a requirement for the developer. Meaning they get fired or fined. This way you protect them and have someon to take responsibility.
When you go to the customer and say, sure we can do this,. It will take 2 months and cost you 20K extra. they may rethink their 'minor' change.
Since the industry doesn't have that, I do it in email. They few times someone tried to call me out, I just forwarded and email and said 'I told my manager it would take this much longer and cost this much more and he approved it.'
While not a lot of legal protection there, it has worked.
Right now I work with a bunch of civil engineers. They get all the same crap software developers do BUT they have legal requirements for sign off, and protection if someone is trying to build something that isn't structurally safe.
When dealing with that, the process will help you because as you go you will have a base of knowledge about how long something takes and what it costs.
If someone wants a , without changing in parameters you need to call them out. Have a process means you have factual backing you can document.
They say that if software developers built house, civilization would fall when the first woodpecker should up.
I wish that was true, because after the last house fell, we would fix it. Instead the industry just slogs through this miasma of low quality slap it together crap over and over again.
Re: (Score:3)
Then you should not use processes designed around the assumption that building something is slow, difficult, and expensive (which is not to say that you should not have processes).
Re: (Score:3)
except programs also take months, cost millions of dollars and aren't easily replaced.
"In software, the process of actually building something is instant, easy, free, and transient"
Yeah, if you're writing hello, world program.
fun and games until the revenue stops coming in (Score:2)
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 ca
Cholesterol (Score:2)
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.
Coming soon to a dev team near you... (Score:2)
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 c
I like reading good code. (Score:2)
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 (Score:2)
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 gr
Methodology == Religion (Score:3)
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 (Score:2)
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 (Score:2)
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
Developers (Score:2)
Good Development Process (Score:3)
A good development process can alleviate many of the problems with having to do all that testing as you test because you have a bad development process wherein you are unable to easily have the developer look at his comments, his documentation and his clearly written code and go 'oh thats the issue'
Not saying this will ELIMINATE the need for testing but this reduces the need for at least 30-50% of it if everyone is properly trained in a good development process and it is enforced.
Re:TDD (Score:5, Insightful)
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.
Re: (Score:3)