Slashdot Mirror
It's Not Developers Slowing Things Down, It's the Process
An anonymous reader writes: Software engineers understand the pace of writing code, but frequently managers don't. One line of code might take 1 minute, and another line of code might take 1 day. But generally, everything averages out, and hitting your goals is more a function of properly setting your goals than of coding quickly or slowly. Sprint.ly, a company than analyzes productivity, has published some data to back this up. The amount of time actually developing a feature was a small and relatively consistent portion of its lifetime as a work ticket. The massively variable part of the process is when "stakeholders are figuring out specs and prioritizing work." The top disrupting influences (as experienced devs will recognize) are unclear and changing requirements. Another big cause of slowdowns is interrupting development work on one task to work on a second one. The article encourages managers to let devs contribute to the process and say "No" if the specs are too vague. Is there anything you'd add to this list?
Take managers out of the equation and work gets done. Pretty simple.
This is my sig. There are many like it but this one is mine.
I insist on the right to refuse any tickets from the moron in sales who never makes a fresh pot of coffee when it's out.
Don't mess with my programming fuel!
I do not fail; I succeed at finding out what does not work.
The project planning, then replanning, then forecasting, then reforecast, then burndown, then plan the next sprint, then perform a retrospective on the last sprint, then update your work items, then explain the deviations, then participate in the daily scrum, then attend the weekly project status. Oh yeah, then do a little bit of the work you've been churning over for the last month. Planning is fine but the point of development is to create solutions. Not plan to create solutions.
Please pick up any courtesy phone in the lobby and read out any and all relevant chapters.
I am Slashdot. Are you Slashdot as well?
Sorry, I think I have a case of the Fridays.
When I worked as a lead video game tester at Accolade/Infogrames/Atari (same company, different owners, multiple personality disorder), my schedule estimate for code release was always accurate (+/- two weeks). Unlike the developers and producer, I didn't get a completion bonus for hitting the milestone dates. Their bonuses would fly out the window because they spent so much time trying to hit milestone date that the game couldn't pass QA. Not my fault that they can't code in a timely fashion.
Sure, people at all levels should be encouraged to say "no" if other things are wrong too; for example choice of architecture, data model, choice of development environment, language or database...
Unfortunately, I've seen too many projects where people - including me - said "no" very loudly on these and similar issues and...were ignored.
Hilarity ensued.
On time completion: It will be done as soon as it can be done, only experienced teams can provide reasonable estimates, developers provide timetables not managers, there's a specific amount of work that must be done before release and putting dates on it won't reduce the total amount of work that needs to be done.
Unclear requirements: It's now the developer's job to talk to the stakeholders and find out what all the requirements are at the point in time they need to size or implement them. They get a vague 'story' that gives an overall concept of a requirement, and then it's up to the dev to talk to whomever needs talking to, then.
Changing requirements: This happens and everyone expects it. So you do only the least work required to complete each requirement so the overhead in a change will be the smallest, and then you just pop that item on the queue and it gets done, that's it.
Context switching: Tasks are assigned to a team by managers, not as a sole developer, so if context switching is causing a problem, it's up to the team to figure out how to minimize it.
Take responsibility: They are, and increasing the duties that a developer has, while removing certain responsibilities from managers and product owners, which more accurately represents the reality of the situation.
Caveat: Recent studies have shown that Agile is not as good as a waterfall-agile mix, where you do a good amount of planning (especially architectural planning) prior to the agile-like development, which makes a lot of sense. If half your work effort is refactoring, at some point you start take a severe hit to either efficiency, quality (robustness, maintainability, operational limits like memory or speed, etc), or time.
I'm surprised knowledge is not listed on there.
I guess it depends on what you work on. But in many places I've worked, you are interacting with other pieces of software both old and new. Often times interacting with these is a bit of a void and you end up having to figure it all out, which is error prone.
Knowledge maintenance is not something that is accounted for in the process. Heck, you could probably even get accounting on board with that one.
The other part of it is a lack of devops.
A big part of the blame here lies with developers who think of themselves as rockstars, compensating with late night heroics to solve problems that really should not happen in the first place if the process was done and funded properly.
The differences are more along the lines of:
1) You often don't know code is bad - or how to write good code - until after you have done the work once. So effectively it can take twice as long to write the good code - once to write it badly, then again to write it well.
2) Good code usually requires a good working environment. You can never write good code while your boss is demanding you hurry up and finish the project.
excitingthingstodo.blogspot.com
Quit RIDING MY ASS, Jim!
SJW's don't eliminate discrimination. They just expropriate it for themselves.
Of course, one could theoretically argue that working for an employer who won't give due consideration to a developer's input isn't worth working for in the first place, but that nice little theory doesn't pay the rent. Oh, and try explaining to a future would-be employer about why your last job didn't work out... care take a guess how that will go down?
Of course, it might seem that working for yourself solves much of this problem, but even that still requires that you actually have paying clients, enough of them that you can support yourself on what they are willing to pay you. Of course, then you are actually back where you started, where saying "no" to a person who pays you money to do whatever it is that you do carries a risk of not getting paid by that person again. If you have enough clients, this may not be a problem to lose the odd one or two because they are dillholes, but getting to that point will take time... possibly many years... so until that time comes, you'll just have to do whatever the heck the person who is paying your salary tells you, unless you really have an affinity for living in a cardboard box on the street.
File under 'M' for 'Manic ranting'
Expensive consultants have released a shocking report demonstrating that water is wet.
http://yetanotherpoliticalrant.blogspot.com
The article encourages managers to let devs contribute to the process and say "No" if the specs are too vague.
Well, I hate getting into a process too early and I hate getting into a process too late. Too early and they still haven't agreed on what it is they want, why they want it and you end up wasting time listening to a whole lot of arguing and proposals back and forth that have nothing to do with the technical feasibility of any solution. It's like having the chef waiting while the guests are debating fish vs steak vs chicken, they're all good dishes so pick the one you want. It's another thing if they're looking for help at finding a best practice, but in my experience they don't look to IT for that.
Come in too late and the requirements are woefully inadequate while the solution is half-designed with no regards to sanity. Like a proposal I recently reviewed, it had very little in terms of objetives and results but an almost complete IT solution that'd be a technical, administrative and logistical nightmare. Written by somebody knows the subject matter very well but has never managed more than his own laptop, my Dunning-Kruger meter went all the way to 11. And he wins most arguments by exhaustion, he makes these long deliberations in a slow, monotone voice that drives me nuts.
Live today, because you never know what tomorrow brings
If "working on your tan" counts as work, sure.
The last thing you want to do is quickly release an application that people do not understand and that doesn't do what is needed. A delay in release is much preferable. Multiple prototypes and user studies may be needed to clarify those vague specs.
Yes, discipline is needed and indecision can be taken to extremes. But most apps/services fail because they have not been adequately thought through rather than by launching late.
None of the companies that I've ever worked for exercise that principle.... in my experience, if you are incompetent at what you are asked to do, then you are fired. If you are just barely competent enough to keep your position past your probationary period, then this would come up during an annual performance review, with a critique on your work habits and what you can do to improve. If no improvement is noted over the next several months, you will be laid off. In my experience, if you are going to get promoted, you will need to go above and beyond what your job expectations are, and show the employer that you are capable of taking on greater responsibilities than what you were initially hired for, while still meeting all of the expectations of your current position. If there are no exceptions to the "Dilbert Principle", then how does that experience jive with promoting the least competent people to management, exactly?
Or are you incorrect about your assertion that there are no exceptions?
File under 'M' for 'Manic ranting'
Don't hate the player, hate the game.
Trouble is, the game never changes.
Get the meetings in check.
A good manager can isolate devs from most meetings and will efficiently communicate what needs communicated. Unavoidable meetings should be scheduled for as short a span as possible and must end on time, no exceptions.
... regarding feedback, see bret Victor on this. Computer programming is different from building bridges because every time you change code you change everything that interacts with it. Whereas the laws of nature for bridge building don't change, every time you modify code you end up having network effects that effect every instruction afterward.
http://blog.codinghorror.com/v...
Since most (non multi-core) code happens sequentially. To see this, imagine an extremely simple computer with only a few KB of memory, all you are going to do is draw something. Every time you add more code, you change the nature of the problem, this is hard to see but the best way to visualize it is as a "ring" that expands or contracts vs the computers resouces. We'll use a metaphor for hitting targets for the goal you want to accomplish: Say the target you want to hit is a circle of a given size and everytime you grow the ring (code) you begin to miss the target (aka the ring grows because of more work/timing/etc). You have to stay roughly the size of the fixed target but you don't fully grasp the nature of the problem, partially because the feedback process is broken with coding tools and performance against the problem (requirements) you are trying to solve is unknown until implementation.
I'm work for an organization that provides design services (as opposed to building and selling products). If you are ever, ever , realistic about the time it will take to deliver or what features you can include in a design for a given set of resources, you won't get the job. It's as simple as that.
Why do you think most construction projects go over budget? One big reason is they had to make a crazy bid because if they didn't, someone else would.
The bottom line is: if you say no, you're out of a job.
I've done my time as a technical project manager. I can't say I enjoyed it, but someone had to do it, namely protect the developers from upper management so that they could actually get their work done. One thing it taught me was to plan around 30% of the project time on the requirements. That still seems insane to me, but that's what it takes. That was my time, working with upper management, documenting things, listening to them waffle, and generally refusing to hand anything to the developers until I had a firm set of requirements, signed off in blood.
When they would then immediately try to change. So during the implementation phase, the two challenges were (a) refusing to accept needless change requests, and (b) having to literally forbid upper management from talking to my developers directly, because they would direct them to make changes that I had already rejected. That latter led to quite a stressful little showdown :-/
FWIW: small companies are a lot easier to deal with than large companies. They have fewer managers and less time to waste on endless meetings. Usually you have a small group of people who really need to be elsewhere, so you can reach decisions fairly quickly. With large companies, there are apparently endless numbers of middle-management drones who want to put their oar in - or maybe they just want the coffee and donuts.
So: 30% requirements, 30% QA/Testing, and 40% development - that's about how the work hours broke down. Calendar time was different, with the requirements phase sometimes taking many months even for relatively simple things that were developed in just a few weeks.
Enjoy life! This is not a dress rehearsal.
The team I work on reports to a senior director who abhors process. His distaste for it comes from his roots as a rockstar developer at a startup. He often says things like "we just need to fix it" or "this should be simple" and gets frustrated in meetings with teams who push back asking for more information. While being very vocal in meetings, he never creates any documentation or requirements to guide teams. Nor does he consider the impact of the changes to, what can only be described as a giant hairball of a product that we work on. As a contributing software engineer and scrum master, he makes my job very difficult at times. Particularly because he has no respoect for the process and does not develop crisp requirements. Our critical response team (for bad customer issues) also is a direct report to him so he will often distract teams with firedrills, trying to shoehorn code changes and testing into the development process that is already underway. And his firedrills often have no bounds.
My point is that process, whether it be agile or waterfall, has to be respected in order for development and test teaams to run efficiently. One bad apple, higher up in the management hierarchy, can grind a large group of engineers to a halt. Talented engineers who are unproductive will have low morale and will start looking at other opportunities. All of this will cost a company a lot of money.
It is easy for a developer to bitch about process and avoid it like the plague, yet the stuff (s)he actually works on is usually a direct result of that hated process. Individual contributers can skirt a lot of that work and still help the company achieve it's goals. But when that attitude creeps into maangement get ready to watch things fall apart.
More flair! More cowbell!
It depends which parts are "agile" and which are "waterfall". From my not-exactly-vast experience, whatever mix you choose has to address four concerns:
1. WHAT ARE YOU BUILDING? Seriously. This is where the extra planning of "waterfall" -- itself a misunderstanding of someone else's comments -- comes in. One of my first jobs was a derivatives trading app in a perpetual tug of war between an outspoken exotic derivatives trader, back office and compliance folks wanting to automate trade reconciliation, risk managers wanting to manage risk, and the rest of the trading desk who just wanted to price whatever deal they were trying to do (vanilla or not). The end result was a kludgey mess that everyone hated.
2. HOW DO YOU ALLOW FOR GROWTH? There are right ways and wrong ways. Agile has a good tip: build only what you need, and as cleanly as you can. Better said than done, of course, and sometimes (as the Pragmatic Programmers have said) you *know* there will be a database in there sooner or later, so plan your architecture accordingly even if it's a little awkward short-term. Then there's the wrong way, which I saw in one project: build a "flexible" architecture with "configurable" components so that you can do "anything"! 1) KNOW WHAT YOU'RE BUILDING, even in broad strokes (see above). 2) For software to be reusable, it must first be usable for *something*. 3) If your "flexible" and "configurable" architecture takes more time to modify than writing straightforward code would take, it has failed; start over. 4) It's better to use open-source architecture than build it yourself. (Buying is also better, but beware of vendor lock-in and every-increasing fees, especially if you only use a small part of an elaborate framework.)
3. HOW DO STAKE-HOLDERS REQUEST CHANGES? No specification will be adequate out of the gate, and unless you're working for NASA or the military people CAN and WILL request changes, sometimes while you're building the product and certainly once people begin using it. Do you jump when they say how high? Do you have a long and slow review process? Do you work individual tickets? Do you have potentially disruptive "projects", and if so how do you integrate them back into the main project? Different applications have different rates of change and different tolerance for defects, but it's best to work out change process before the complaints come in.
4. WHEN AND HOW DO YOU CUT YOUR LOSSES? Despite your best efforts the whole thing will become obsolete or unmaintainable, sooner or later (hopefully later). As in point #1, have some idea which you're building, and at what point do you deprecate it to build something better. (This is the hardest part for many organizations; why can't the floor wax also be a salad dressing?) At some point make a plan, refactor your code base -- over time! -- to separate the parts you'll keep from the parts you don't need, and toss out the latter. If a radical rewrite is the only way to go, bite the bullet and do it, with appropriate safe-guards like regression tests. If you can't evolve or replace your product, a competitor -- maybe within your own organization -- will do it for you.
That's my long-winded advice, from someone who's watched many "successful" and "unsuccessful" projects die. Nearly all in-house software is a Potemkin village designed to keep the tzars happy. If the tzars aren't happy, the fake village is set ablaze and you, the fake peasants, go to Siberia. The only real question is how to keep your frantic peasant dance going as long as possible without dying of exhaustion or being sent to Siberia.
TL;DR: Plan the limits, goals, requirements, and large-scale architecture up front (erroneously called "waterfall"). But planning never really ends; stay agile to correct your course or take advantage of opportunities ... and be willing to throw the whole thing away if warranted. Also, keep your resume updated.
To my mind, the best managers set up conditions for their staff to succeed and defend them against higher-level managers. That's it. Managers should take care of head-count and hiring and meetings and all the other boring but apparently necessary stuff; they shouldn't be responsible for *any* analysis and design, let alone coding. Because all the "boring" stuff will eat up someone's time, and better the designated victim, I mean manager, than someone responsible for making progress.
The *worst* managers, in my not-too-atypical experience, are the rock-stars, micromanagers, timekeepers, and corporate climbers. True rock-star programmers should be writing code, not going to meetings ... and if they can't cooperate with the rest of the team they shouldn't be on the project at all. Micromanagers second-guess their staff and the staff waste valuable work time indulging the boss. Management by Gantt chart is even worse, since estimates in software are rough guesses, not contractual commitments; the work takes as long as it takes, for a set amount of work, and forcing the staff to work harder to satisfy a bogus schedule only makes work later (or buggier). Worst of all are the managers who are simply mouthpieces and boot-licks for their bosses, because they'll throw you under the bus for any perceived failure and claim credit for all your successes, often both at the same time.
sprint.ly is trying to sell us their product using slashdot.... Hey, slashdot can you send them a bill for advertisement?
I love H-1B's... every H-1B hired creates the need for two more real coders to clean up their mess! I say, bring them all over!
: )
Uh, Linux geek since 1999.
and I wholeheartedly disagree with the writer's idea that everything "averages out."
Sure it does. The first 90% takes 90% of the time.
The next 10% takes 90% of the time.
Oops - specs changed - time to reset the clock ...
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
So often I see developers and often their managers being loaded down with things that have exactly zero to do with the project's success. For instance I have seen companies that had an 8am meeting every morning at a company that claimed flexible working hours. These meetings were nothing beyond empty platitudes from a manager.
Many companies that I have visited had sales dictating what needed to be built in that they would chase every whim of every potential client resulting in 100's of features being built for nobody (didn't get the client) but slowly turning the projects to crap. Then sales would regularly blame the programmers for letting them down by not developing an AI driven natural language database over the long weekend.
The single worst that I saw was a company where the president's wife suddenly started dictating features. These features were completely unrelated to the core product. It would be like a VW engineer suddenly getting instructions on adding a flower arranging module instead of working on a recall where the cars can catch fire. This had the entire project's staff leave one by one until the project just died.
But if I had to pin project failures down to a single consistent problem it would be that really terrible programmers who are complete blowhards often get way ahead of their co-workers leaving a trail of fuming resentment in their wake; the primary result is that the most skilled programmers are the first to leave resulting in a rapid plummet of the average level of talent as once the best go often the next best are soon to go, and so on until you are left with only duds who don't dare to find another job.
As for what system is in place it doesn't really matter much as a talented group will make it work. But if that system is encouraging any of the above disaster scenarios the project will suffer.
This is a quote from Elon Musk on what he thinks about "process":
"I don't believe in process. In fact, when I interview a potential employee and he or she says that 'it's all about the process,' I see that as a bad sign.
"The problem is that at a lot of big companies, process becomes a substitute for thinking. You're encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren't that smart, who aren't that creative."
This just about nails it for me.
This and no other is the root from which a tyrant springs; when first he appears as a protector - Plato (423 to 327 BC)
Corporate Policies requires that developers cannot have so called 'elevated rights' on a server. Any server, including test and development servers.
Well, that is, the developers have been granted local admin privileges for the development servers, but as a special exception to the corporate policies.
The daylight savings patch that has to be installed, requires an upgrade of the application on the server, with an uninstall and a fresh install.
With a full redeploy of the content and reconfiguring connections to ldap, databases, other servers and reconfiguring user autorizations linked to the content.
The developer documents the deployment procedure in an installation guide.
Next the the upgrade has to be deployd to the test server, but none of the developers have local admin rights for the test server.
So, resources from platform operations have to be claimed by the coordinator. For the installation and the finalization of the application upgrade.
The upgrade takes a little more than the standard 2 hours that have been reserved per week, but finally after a week a slot is available to do the part that has to be done that requires local admin rights for the test server, by someone from platform operations.
At this point, the system test has slipped by a week, on a monthly release cycle, that is a significant amount of time.
A couple of day later the upgrade is deployed to the acceptance server for user testing. Except that most of the users refuse to test the changes, because there are no new features. In their eyes it is purely a technical upgrade. Nevertheless a bug has been found, and it is declared blocking. It takes some days to resolved it. By now, due to all the previous delay, the issue has not been resolved in time to get the change in production.
The monthly release date slips. The next slot available is the next month, and the application gets finally released into production.
Essentially, it means that if something does not get tested beforehand, like a deployment procedure, it eventually gets tested in production.
That is the best way to test something, isn't it? A consequence of the Corporate Policies.
Absurd?
Now I am going to watch some South Park episodes. I like documentaries.
For these groups: middle management, "UX" design, human resources, and everyone at or above executive level...
They get their own building, with its own network. We''ll call it location "E." The network is in no way connected to the outside world. There is no mailroom, and no delivery access to the building. All vehicles in the parking lot are to be classic Pintos. The parking lot shall be liberally equipped with speed bumps.
Developers, Manufacturing and Shipping work in another building or complex. We'll call it location "D."
Location D requires its own badges. You can't get past the lobby security installations if you don't have one. If you try, you get dumped in an unmaintained pond over-populated with carnivorous ducks carefully selected for unusually unsanitary and highly aggressive natures. To protect these wonders of evolution, the pond shall be patrolled by duck enthusiasts with fully automatic weapons.
Location D has its own network, which is firewalled at every possible level against anything, in or out, from location E, as a prophylactic measure, should location E somehow arrange for a WAN connection.
At location D, the janitorial staff shall work hand-in-hand with the mailroom to heat the building by incinerating any mail or package that isn't (a) a paycheck, or (b) items that are on a list of things previously ordered by the occupants of location D.
Location D shall have its own high quality NY pizza shop, a Dunkin Donuts, and an Orange Julius. The mailroom shall be responsible for delivery of products from these to the developer's desks, and for running out to fetch non-local take out orders. Mailroom salaries to be commensurate with consistency of their on-time, still-fresh delivery records, which shall be kept in consummate detail.
At location D, female developers shall have hot male sexataries with pole- and stripping-experience. Male developers shall have hot female sexataries with pole- and stripping-experience. Poles shall be conveniently located in and/or near all developer offices. The sexatarial pool shall have both a shallow and a deep end, a selection of diving boards at varying heights, and a suitably awesome sound system and snack bar, and it shall be located adjacent to a well-equipped workout center. Fridays shall be devoted to data collection by careful developer examination of active poles.
Location D shall have a rooftop laser tag facility with long-range light-arms. Location E shall situate all offices such that they have windows facing location D, and all location E personnel shall be required to wear lasertag suits that (with one exception) simultaneously initiate a period of physical incapacitation (locked limbs) and a significant shock. The single exception to this rule is that at location E, the vests worn by UX designers shall be equipped to deliver fatal shocks, whereas the incapacitation feature is to remain uninstalled in order to save the company money.
At location D, any occupant of an office that wishes the title "rock star" to be affixed to, or adjacent to, his or her door must demonstrate the ability to actually perform rock and roll using an actual musical instrument to a panel of rock and roll enthusiasts suitably selected from the ranks of the developers. Air guitar does not qualify. Singing ability may qualify, at the discretion of the panel. Developers so qualified shall be additionally eligible for multiple sexatarial personnel/services, a small but well-equipped stage, and their own snack counter.
All developers shall receive 1 (one) exotic car of their choice leased for them for the duration of their employment, funding for which shall be achieved by garnishing executive salaries as needed. The location D parking lot shall provide direct access to both high speed oval and full scale Nürburgring-configuration tracks. There shall be no speed bumps in the location D parking lot, however, the west extent of the lot shall be configured as a 1/4 mile track with a 1/2 mile rollout at the end.
At location D, there shall be a Lego parts acquisition department, which shall be expanded as developer needs require. All offices shall have a lego assembly and display area.
I've fallen off your lawn, and I can't get up.
I work at a company that tends to be ahead of schedule and so we get time to improve things, and improve things steadily. We're not typically stressed and usually pretty confident about stuff.
This just reminds me even more how much I love my job.
Not every Agile process recommends that kind of approach. I teach Agile development, and I certainly don't. When you see a lot of final year student projects, you see all sorts of interpretations of "Agile" methodology, from utter adhockery to an approach that's waterfall in all but name. The more successful students, and successful projects, will take the time to carefully design the parts of the system which are a) high-risk, and b) difficult to change, and don't bother with trivial design for simple, easily modified parts of the system.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Maybe it's just me, but Agile and waterfall development seem like orthogonal concepts that don't exclude one or the other. Waterfall probably needs to be tweaked a bit to work for a team using Agile, but other than that, I don't see any reason why it still couldn't be used as model for project management even if Agile is used.
// file: mice.h
#include "frickin_lasers.h"
They key word here is "small". The complexity of managing a company grows at an geometric rate as a function of employees. The complexity of a project grows at an exponential rate as a function of the number of developers (at least after you get past a handful of people). Small companies that don't produce quickly die. I work at a medium-sized company where the scaling issues I described above really apply, so even though it's a good environment and management isn't a hindrance to making things happen, there's no way I would say work gets done quickly. However, the work does get done, and the environment is such that I feel like I can really make a difference. This contrasts to when I worked for a large company where I felt like nothing I said or did mattered in the long run (even though I did really good work for them.).
It sounds like you are in a good situation, and I hope it stays that way.
You are in a maze of twisty little passages, all alike.