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?
I need your TPS reports now and don't forget about the new cover letter on them as well.
This is not exactly accurate.
Refer to "The Dilbert Principle".
Do not think there are exceptions. Anywhere. Ever. Notta single one.
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.
I might consider myself lucky then, because I have a manager (he's also the owner, it's a small company) who is a software developer and we get work done very, very quickly when we focus on projects together.
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.
Why, it's those vague specs and bug reports put together by the managers and support folks that's been slowing us down!
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.
...quantify IT work and I wholeheartedly disagree with the writer's idea that everything "averages out."
Because it doesn't. Never does.
In many situations, you wind up being hired into multipurpose roles where you can solve "general problems" using a plethora of multifaceted solutions (which you realize you frequently need to resort to due to the realizations inherent in subsequent scoping). But because of this and the cart-before-the-horse evolution this field is known for, there is just never a "general" solution! That just doesn't exist in this work! That's why we keep running into this problem over and over again...
A 100 or however many years from now, I believe programming languages will begin to settle down. You'll see more and more be consolidated into more formal languages that last longer without major revamps (or so, this is my hope). Assuming this ever happens, you'll begin to see things be a bit more stable whereby metrics most managerial staff love to see might then become possible (i.e. - "How much time will x-y-and-z take?", "Can we use the last estimated time amount from the last project and apply that to the new?", etc.) ...another major issue here is the fact that developers still allow their lives to be dictated by employers. If all the developers banned together to form either some sort of union or else just went to business on their own, they'd own the world. The problem, though, is that despite their omniscience, they just can't ban together enough to do this. Must be ego...
Stakeholders have to understand the cost (detriment?) to benefit. Adding functionality is more than adding the feature, it's adding the lifetime care and feeding of the function.
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
Competent management is rare. But when you get it, it's absolutely worth its weight in gold.
I've had fantastic managers who've shielded developers from the HR / corporate nonsense, while keeping realistic schedules and checkpoints. At best, they are your advocates, and let you get on with solid work, with a minimum of interruptions. And they earn when they go into bat for you - if the higher-ups keep getting the spec wrong, or it's a moving target, a good manager makes the case for more resources. Anything else just ends in overshoot, and ultimately costs more in the long run. Under-estimation always ends up costing more, while damaging morale and possibly resulting in people resigning.
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.
That's why it's called Engineering.
Writing code is quick if you (precisely and accurately) know the goals it must achieve. Establishing those goals and ensuring they've been met are not trivial.
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.
When I code I take projects on the side.. side jobs. I know how long a project will take me. I also know what code I am going reuse and what i am going to write from scratch. Bean counting managers take the fun out of coding. I used to look forward to the hard stuff because that's when I learn something new. Especially when it comes to write a new original algorithm.
The so-called software development methodologies (like Agile, the current fad) are there, for the most part, to justify the jobs of certain managers. That's it.
In fact actually creating code is a largely mechanical task that can be automated. This may either elate or depress you.
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.
I will preface my comments and say that I have been on both sides of this argument, as a developer and as a manager. I learned good management by being managed by good managers.
People talk about these named development models like Agile, Scrum and Waterfall. When I started off doing dev work in the early 1990s we did what is now called Agile development, only for us it was just called good development work, or common sense to involve your stakeholders in the development process and create feedback loops so that bugs were caught early and new features that might come up get integrated before release, if they can. The names for these things keep changing so I don't bother trying to keep up with them, I just implement best practices from experience.
This process, "stakeholders figuring out specs and prioritizing work," should be completed (at least 75%-90%) before development work begins. I have dealt with this issue my entire career. People want to dive right in and start doing stuff before they have a clear path. It's maddening! For some reason people want to shortcut everything and skip step one. First rule of good management (and development) is you can't skip step one, nor can you let someone else above or below you in the organization try. Just diving right in without thinking things through leads to wasted work and project delays. It's inevitable when you don't have proper leadership controlling the process.
A lot of comments above seem to hit the nail on the head and say that a lot of managers are bad because they don't know how to manage properly. These bad managers seem to come into management with preconceived ideas of what their role is from textbooks or from bad managers that they themselves have served under. They have no reference for what good management is and how it is different from bad management.
Touching on management's role again, one of the things I found myself doing quite a lot as a manager was running interference for the people under me when half-baked or just ludicrous ideas were flushed down the pipe at us. I was the one constantly saying "No" and trying to keep my employees from being overworked or burned out because my superiors wanted to do "more with less". I also tried real hard to get interesting and more useful/utilitarian projects into the group to build competency and make the work less monotonous. This lead to some really big projects with some really big positive outcomes for my organization. But, those are rare and so are good managers. Too many of managers are just on a ladder climb and really don't pay attention to anything but their career so they don't care about the developers and others under them. They want something for their resume so they can get the next three to five year position before they move again. Selfish, sickening bastards is what they are. Unfortunately, they vastly outnumber us good guys and often scheme to get the good guys punished or canned because they make the bad managers look, well, BAD!
I am truly empathetic to all those dealing with bad managers. There are far too many of them out there and they defile the pool within which we all must swim. However, sweeping generalizations about management are about as useful as sweeping generalizations about data types.
Developers can say no. However, in this cut-throat market, saying no means being fired for not being a team player, and having your recently vacated position filled by an H-1B visa holder (or two) who can't say no, because they can be shipped back where they came from.
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?
As someone who attempts to cat herd, I have to say that after you've been in the business for a few years most of the articles observations are on the money. I'd add a couple of my own observations to this though, namely:
1) Developers need to play their part in bouncing out of band requests into the process backlog (even when it's a 'easy' glory opportunity) if they are not to undermine attempts to protect them from interrupts.
2) Humans are incapable of predicting the future; requirements will always change. If it's too painful, then it is either a sign of inadequately stakeholder engagement or of a strong need to invest in a process that reduces the cost of iteration (see test driven development and BDD in particular for an idea about where to start with both of these.)
: )
Uh, Linux geek since 1999.
Business Analysts work with the business to set the project scope / requirements to ensure the BUSINESS NEEDS and BUSINESS VALUE are identified and met before the project begins.
Systems Analysts work with stakeholders to elicit functional and non-functional requirements, document them, present them to the Scrum Master / Development Manager / Project Manager, and ensure they are clear and adequate for prototyping / development work to begin, up to and including pseudo-code.
Both of these roles identify the scenarios (Business and System), and Use Cases that would leverage this system / feature, and they describe these as scenarios that are used for both system and user acceptance testing. They also provide the training that would be required for this solution.
Good Analysts make everyone on the team more successful and reduce the impact of the challenges that the article describes. Good Managers hire Great Analysts to make the developers Awesome.
Bad Analysts are another thing entirely, and have the potential to make the effort more difficult and the team members less successful.
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.
Designing a house is different to hammering in a nail...?
Is that once everything is clearly defined, the development is a technical task that we are fully capable of executing in a timely fashion. However, the real creative part is in defining the task! The customer can't define it for you, so the process has to force whatever team is working on things to create that definition. Newsflash: this part is really hard, and usually just gets pushed onto the developer, who has to become a subject matter expert on all sorts of random stuff to both define the solution and develop the product.
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.
SCRUM, Agile, Paired Programming and Java...
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"
Where I work I've seen this happening for years, but rather than being fixed, this slowdown has been exploited. What this article doesn't cover is whether engineering starts these projects too early intentionally. Most of the specs aren't in place but Engineering starts up anyway. Fools in marketing think it's great that work starts sooner, not realizing that starting sooner doesn't mean finishing sooner, and it probably means finishing later. Engineering ( or a software manager or two ) understands this and knows that working this way creates more "billable hours" on a project. Since marketing is constantly updating or completing the specs engineering has something to point to as the cause for the delays. Based on how long tasks take to complete over the years, I've seen managers double the size of their staff. They catch grief over not delivering, but not to the degree that the product managers in marketing do as they can claim the project would have been completed on time if the requirements hadn't changed. Those hundreds of course corrections made over the life of the project increase the time to completion even though the end point doesn't appear to have changed.
Stripping features is another way of "padding the bill". Different factions in marketing all want their pet feature included. But rather than prioritizing the features on day 1, they all have equal priority with work being down on them in parallel. Only when deadlines approach is the work done to pull features that either won't be done or to shift effort to other features. But doing the pruning late in the project means those features that don't get released suck resources from day 1 until they are cut. If / when these omitted features get added to a subsequent release there are efficiency losses due to lack of momentum, change in staff, change in priorities. The company didn't get the feature to sell, but developers still got paid for working on it.
Why would an engineering manager complain about the status quo? They get paid for more hours of work and most of the blame for delays or blown deadlines gets piled on someone else. It's a balancing act though. Do it too much or for too long and the company might suffer enough that they start to fail, or upper management starts looking for more people to blame.
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.