It's Not Developers Slowing Things Down, It's the Process 186
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?
Nope... Nailed It (Score:2)
Re:Nope... Nailed It (Score:5, Insightful)
This is not exactly accurate. It hinges greatly on the type of manager we're talking about.
For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented: This type of manager can actually accelerate the development process significantly since developers now know exactly what to do. But again, this manager has to really know what he's doing, and have some serious programming experience in his past.
Re:Nope... Nailed It (Score:4, Insightful)
Re:Nope... Nailed It (Score:5, Insightful)
That is a good one. Sometimes, managers are having too many projects to manage at once and are experiencing the exact same problem as lead developers. They have to switch context so often they lose completely the focus when time comes to a particular project.
Usually, when a position post description mention: "must work well under pressure", "must be able to multi-task", "seeking for rockstar developer", etc; you can be sure you don't want to work there. It is symptomatic of a shop which operates without enough staff and on low budget expecting miracles to come out from the process.
Re:Nope... Nailed It (Score:5, Insightful)
Especially funny. Rock Stars don't multi-task. They lock themselves away in a darkened office working on the currently interesting single problem until it is solved. Then they come out, decompress, and repeat.
Part of why they have rock star performance is that they don't multi-task and don't sit through endless meetings re-hashing yesterday's meeting.
Re: (Score:2)
Rock star performance is achievable by anyone who gets to focus on just one thing at a time. It's also called being a prima donna, not a rock star.
--#
Re: (Score:2)
Proposal: (Score:2)
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 ca
Re: (Score:2)
...some boilerplate garbage cut and pasted from stackoverflow.
Is the text still available on Stackoverflow following the paste operation?
Then you meant "copied and pasted". Not quite the same thing. You should use the one that actually means what you apparently want to say.
Re: (Score:2)
Rock star performance is achievable by anyone who gets to focus on just one thing at a time. It's also called being a prima donna, not a rock star.
--#
Pri Madonna, a Pop star.
Re:Nope... Nailed It (Score:5, Insightful)
Yeah, my company does that.
75 features to be implemented by the end of the quarter.
2 weeks in, cut it down to 50
1 month in, cut it down to 20.
Actually deliver 12 features.
Planning & prioritization are all over the place for the first month. And code freeze is 2 weeks into the second month.
Every single quarter. Why don't the people expecting 75 features every quarter get fired?
I'm just glad I'm not a developer here.
Re:Nope... Nailed It (Score:4, Interesting)
Couple of big shops in my town. Take one for example. They had a 2-year window for a very important project.
Bought (expensive trendy tool) from (major software vendor). Spent 18 months drawing stick-figure diagrams with (expensive trendy tool). Realized they only had 6 months for implementation and panicked. Basically tossed the stick-figure diagrams because they had to drastically modify expectations to make it in 6 months of 100-hour programming weeks. Using contract laborers who didn't know the company and how it operated, because they'd taken a chain-saw to the ranks of the in-house experienced staff.
I'm sure that they learned a valuable lession from that and will never do anything like that again. I'm also sure that pigs fly and cows routinely jump over the moon.
Re: (Score:2)
I'm sure that they learned a valuable lession from that and will never do anything like that again. I'm also sure that pigs fly and cows routinely jump over the moon.
This is a good illustration of the folly of top-down "waterfall" methodology. Too much micro-planning in advance, no action.
Re: (Score:2)
I'm sure that they learned a valuable lession from that and will never do anything like that again. I'm also sure that pigs fly and cows routinely jump over the moon.
This is a good illustration of the folly of top-down "waterfall" methodology. Too much micro-planning in advance, no action.
Well, they also think that they're "agile". And have another expensive trendy tool to ensure it.
Re: (Score:2)
Well, they also think that they're "agile". And have another expensive trendy tool to ensure it.
But according to the description their methodology very clearly ISN'T "agile", whether they think so or not.
Agile isn't a tool, it's a method. And that method doesn't include eons of top-down planning, no matter what tools are used. But I may be preaching to the choir here.
Re: (Score:2)
Re:Good managers manage up, not down (Score:2)
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,
Re: (Score:2)
This is not exactly accurate. It hinges greatly on the type of manager we're talking about.
For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented: This type of manager can actually accelerate the development process significantly since developers now know exactly what to do. But again, this manager has to really know what he's doing, and have some serious programming experience in his past.
Do agree it depends on the type of manager; but they don't necessarily need to know the subject matter to be useful and accelerate the project; sometimes a technical manager an make things much worse.
I had one that gave me a very broad goal - produce a GUI like X for the application. He was fairly hands off, and things got done. He knew his limits and relied on the people under him to overcome those limits.
I had another that was techical, but tried to be hands off - that is, until things weren't going
Re: (Score:3)
That's a manager who manages down. Most managers manage up.
In my ~15 years of experience "manage down" managers are hurting their career advancement prospects by helping the company deliver. It's one of those corporate blackholes. Normally if you take care of your house, you have a nicer house to live in. If you maintain your car, you save money and have a more reliable car for longer. But in the corporate world, investing in yourself is usually trouble.
Not everywhere, but 3 out of my 4 employers.
Re: (Score:2)
But in the corporate world, investing in yourself is usually trouble.
I worked at one company that wouldn't train workers since management was afraid that they would get certified and go work for a competitor. Never mind that most employees were training themselves, getting certified and leaving for a competitor anyway.
Re: (Score:2)
For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented: This type of manager can actually accelerate the development process significantly since developers now know exactly what to do.
With this type of manager, as a programmer, you have to write exactly what he wants, and it's completely demotivating: the programmers cannot take any initiative.
A manager must be available.
Instead of mock-ups, diagrams, etc..., he/she must be available when the devs need him/her when some "obvious" feature is not written in the specs, or when to validate this or that feature.
If the manager is never available, because he/she spends his time detailing the process or spending time in meetings, his/her team wi
Re: (Score:2)
Vague specs are bad. But.. there is little I hate more than when they go the other route and try to fill in all the techical details. I've received a lot of specs that already included things like database schema complete with really bad table implementations and duplicated data all over the place.
Re: (Score:2)
As a dev myself, I'm absolutely fine working with vague specs. As long as my manager accepts a few iterations for fine tuning. And considering the time that is spent for planning the smallest of details, that may even be more productive.
Just don't give vague specs and complain about not sticking to them exactly.
Re: (Score:2)
Actually, one of the best things the manager can do is shield the team from other managers, and support them when talking to others.
Re: (Score:2)
> For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented
Then I'm afraid that nothing will get done, because the "proper mockups" take so much time to develop and build that they literally lock up all management time and prevent the developers from being able to write even a single line of code that actually does anything not already hand-written by management.
Re: (Score:2)
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
Re: (Score:3)
One problem with discussions like this is that there is a lack of consistency in titles and job role naming across companies.
For example, in some companies first level managers of developers are not very technical (fortunately, I've never worked at a company where this was the norm) and can only manage work units and people but not solve technical problems themselves or provide detailed technical guidance. They can be good people managers, good at working the politics, good at making sure that the project d
Re: (Score:2)
Take managers out of the equation and work gets done. Pretty simple.
Pity it will be the wrong work getting done. On the upside life is simple.
Re:Nope... Nailed It (Score:5, Insightful)
You don't want to take managers out of the equation. They're the only people keeping the other departments from running you over. You see that most clearly, ironically, when you have an incompetent manager and you get run over in spite of it.
And a bad manager in this sense isn't the evil taskmaster, it is the guy who has no idea of his team's capabilities and taskload. He's also probably a little clueless about what is or is not possible, but in that sense, it's more of a feature of him making promises without talking to the rest of the team first. That manager goes to meetings and lets himself get cowed into submission when sales or marketing goes after him because he has no facts. Removing someone in that position just means that engineering is no longer even a speed bump to unrealistic goals.
Saying "No" to business people is not a valid strategy. You'll just find yourself replaced. Saying, "yes, but you'd need to spend 2 million dollars on it" with proof is a valid strategy. You don't want to sit around and come up with that data, that's what the manager is supposed to do.
I agree that indecisive managers and overwrought process is probably the top cause of problems with productivity. However, there are good managers and bad ones. It pays to understand the difference.
Re: (Score:2)
The problem with that particular notion ("Yes, but you'd need to spend...") is that they're oftentimes NOT savvy enough to grok where you're coming from and they'll just hear the "yes" and make you try to jam 18+ months of dev effort into 6-8 months with the typical, classical, predictable failures, in spite of explanations why it just won't work with their notion. They hear "yes" followed by "wah...wah-wah...wah-wah-wah" like on Peanuts animated features when the adults talked. The "yes" means to them
Re: (Score:2)
And, if you've not figured out what I'm trying to tell you, my answer in your example would be, "Unless you want to spend two more million and spend 12 more months in development, and COMMIT to that- no."
The idiot notion of not being "negative" is fantasy that some crazy HR people came up with to whitewash over the real problems going on in a given company. You need to not just simply say, "no", but in the same vein, trying to not say no is stupid, crazy, etc. Sometimes things ***ARE*** really negativ
Re: (Score:2)
Of course, there is a time and a place for saying "No". However, there needs to be an understanding that engineers are there to make things happen. Business people aren't trying to get developers to do things because it amuses them to do so. So, there needs to be an understanding that while there are times to put your foot down, it is far, far better to be able to explain the level of effort required to achieve that goal and give some alternatives.
You want to be in a position where you get them to say, "
Re: (Score:2)
And let's not forget another role of manager - managing the customer.
Unless you want to dress up in a suit and tie because the customer expects it (some do) and babysit them for the week they're here and interface with them, those are tasks best left to the manager.
Dealing with customers is a huge part of being a manager because customers can become extremely demanding especially if they're doing site visits and need to be babysat. Best to have someone else being interrupted every 5 minutes than you trying
Re: (Score:2)
Re: (Score:2)
Sadly, the JIT model is the only way to work in a mess like that...followed up with plans to vote with your feet.
Re: (Score:2)
I agree that Sales or whoever should trust your judgement, but bear in mind, as much as we joke about Sales or Marketing, they're usually not actually morons. They just have different goals.
A product person who is in your business vertical knows what companies around them are doing. They sometimes are past developers or technical management. They are usually well informed on their market segment. If they want something, they're doing it to make themselves look good by delivering money to your company.
Th
Re:Nope... Nailed It (Score:4, Interesting)
Take managers out of the equation and work gets done. Pretty simple.
Yes, but what work gets done?
Is it the sexy feature that the dev has been just dying to implement since he/she read about some new language/process/data type de jour?
Or is it fixing the hard to locate bug in deep in the back end that deletes all the users data on seemingly random occurrences (and can be brushed off in dev's opinion as merely an aberration)
Re: (Score:3)
I completely agree with your point, but would like to observe that senior or mid-level management always cares the LEAST about fixing old, broken stuff.
Every place I've worked has had serious ghosts in the closet, but projects to go clean up old messes never get approved. This has been true across business, IT, and de
Re: (Score:2)
My experience has been that managers care a *great* deal about users (read clients) calling in and complaining that their data is gone and threaten to sue.
Then again, I mostly worked in banking where reducing risk was a prominent concern for all parties.
Re: (Score:2)
Actually, this is all stuff known to project managers.
When a project is initiated, the Project Manager first creates a Project Charter. This is done by identifying stakeholders (people doing the work, people affected by the work, people receiving deliverables... any individual or group who affects, is affected by, or perceives itself to be affected by any activity or outcome of the project) and gathering preliminary project requirements. Essentially, the project manager talks to the stakeholders to roug
Re:Nope... Nailed It (Score:5, Insightful)
That's nice, you left out architecture. Who's doing the overall architecture? Has it been done before? If it is new, better spend a lot of time doing the architecture. Unless....
You have caught Agilitis. In this case, spend no time doing the architecture up front, do it on the fly. Add time to every single task you think you see for doing architecture related stuff. At the end, allocate a large blob of time to figure out the correct architecture rather than the one you built which now resembles a dirty snowball. And begin rebuilding the thing, reusing any errant parts you did in pass one. And because you are agile, be sure to appropriate time for execs who understand agile as they get to change what's necessary on the taste of their coffee that day, whether their secretary gave them a perky Good Morning, or whether their hair will turn sufficiently silver in time for that next promotion.
Re: (Score:3)
Your argument is nonsense and can be extended to: he didn't even mention the servers, be sure to add a few megs of RAM for each feature to developed, and some HDD space too. Oh, and increase the chip speed for each new feature as well! Then later but new servers to replace the cobbled together disasters you built on the fly.
We use Agile for the *development* process which is distinct from the *design* process. That is, we do architecture up front, including DB design, and - surprise - we even build the serv
Re:Nope... Nailed It (Score:5, Insightful)
We use Agile for the *development* process which is distinct from the *design* process. That is, we do architecture up front, including DB design, and - surprise - we even build the server platforms too!
Don't ever leave your job unless this is becomes no longer true. So many people think agile is free tick to skip design and when wonder why agile isn't saving them from creating a pile of crap.
Re: (Score:2)
Maybe you guys do, in which case it will probably work out fairly well. Most places use Agile for design and development- in fact Agilistas will claim that any time spent on design is wasted, and that one of the benefits of agile is not needing to do design, that a design will form as you go naturally. It tends to turn things into a major cluster fuck.
This is a misunderstanding of Agile IMO (Score:2)
Re:Nope... Nailed It (Score:5, Insightful)
First, that doesn't seem to be what the article is saying. Second, I don't really believe that it's true.
When I say "don't believe that it's true", I'm saying, "I don't believe that the removal of managers necessarily gets work done faster." I'm not talking about programming specifically-- I'm not a programmer, and managing programmers is not my expertise-- by my general experience is that a lot of people think managers are just wasting everyone's time, when the reality is more that most people don't understand what managers do. Unfortunately, this sometimes includes managers.
A good manager often spends his day trying to figure out how to remove obstacles so that the people he's managing can just do their jobs. For example, the summary says, "The article encourages managers to let devs contribute to the process and say 'No' if the specs are too vague." That sounds right to me. First, a good manager will of course listen to the people he's managing. That doesn't mean doing whatever they say, but when I have managed programmers, I assume that they know what they're doing better than I do, so if they say there's a problem of some sort, there's a problem of some sort. I wouldn't always go with their recommended solution, but would I listen to their explanation of the problem and try to come to a solution that addressed the programmers complaint as well as meeting the business needs we were trying to address.
If specs are too vague, that seems like the sort of thing a good manager would help to work out. For example, I might suggest talking to the programmer, trying to figure out which aspect of the specs are too vague, and then meeting with the stakeholders to try to clarify the specs. I wouldn't necessarily make the developer get involved in the process of clarifying them, since unless they're needed for the discussion, they probably have better things to do.
But being a good manager is pretty difficult in general. It's often not clear what needs to be done, or how it ought to be done, and it's your job to figure that out. It's pretty much impossible to be a bad manager without annoying people, but even the best managers might seem annoying or clueless because you don't see what they're doing for you. Sometimes good managers are only noticeable in their absence-- when they go away, you suddenly go "Oh jeeze, things are falling apart a bit here. How was it that we never had these problems before?" And the answer is, you were having those problems, but your manager was dealing with them when you weren't paying attention.
Re: (Score:2)
Turn around.....the congregation is over there. This is the choir. But preach on.
Re: (Score:2)
My manager never gets involved into the development process except when there's an escalation, usually from me. He's there to help me overcome hurdles, nothing more. And he's been really good at keeping stupid people at bay.
Re: (Score:2)
Re:Nope... Nailed it in crooked, but who cares (Score:2)
If "working on your tan" counts as work, sure.
Heh (Score:2)
: )
Elon Musk on "Process" (Score:3)
This is a quote from Elon Musk on what he thinks [wired.com] 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.
Re: (Score:2)
Absolutely. Wasn't it the Bard who said, The first thing we do, let's kill all the process junkies!?
Or, in this more enlightened era, maybe we can send them out to work on a farm for awhile--the fresh air, sunshine, and exercise would do them a world of good, and they'd at long last get the chance to learn a useful trade. Not to mention the most excellent poetic justice factor when they're the ones shovelling the horseshit...
Re: (Score:2)
I played a funny card game once where the engineers would work on projects indefinitely until you got a release manager card to make sure stuff really ships.
One more right of refusal (Score:2)
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!
Re: (Score:2)
French press, hand grinder, beans, and boiling water, baby. Unadulterated and cheap.
You will never want to touch drip or machine coffee again.
Paging Fred Brooks, paging Fred Brooks (Score:2)
Please pick up any courtesy phone in the lobby and read out any and all relevant chapters.
Re: (Score:3)
Untie the bonuses from the schedule... (Score:2)
Re: (Score:2)
This statement always make me laugh. How can you plan how long something will take if it has never been done before? You can't, and in the case of software it has not been done before. The managers are applying the same planning process that is used in less creative processes like road-building, bridge-building, building construction etc., where each task has already been done for decades or hundreds of years so you know how long some task will take.
Re: (Score:2)
The marketing department are applying the same planning process...
FTFY
Re: (Score:2)
The sales drones...
FTFY
Re: (Score:2)
If the task in front of you is so revolutionary that it has never been done before, then you really are building a prototype. This belongs in the realm of R&D which has its own theories and methodologies for handling project scheduling. However, most software projects are built using a set of known technologies. If you properly decompose your system design, an experienced developer should be able to estimate the amount of time required to code each part with a reasonable margin of error. So you are
Re: (Score:2)
Programming is not construction. Programming is design. It's always going to be fuzzier than actual production.
Manufacturing, in software, is trivial. This apparently leads people to think that software development is something like manufacturing, because they want a visible step there.
Re: (Score:2)
In that sense, I think it's also about setting realistic expectations. With almost anything you want to do, there's some limit to how fast it can be done, even with unlimited resources. Limiting the resources available below the optimal level will increase the amount of time to accomplish things. So you can't take a project that will take 6 months to complete, cut the resources to keep the budget low, and then set a project schedule for 3 months and expect it to work.
After a certain point, providing big
Say no, nobody listens... (Score:2)
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.
Agile is supposed to fix these things (Score:5, Insightful)
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.
Re: (Score:2, Informative)
Yes, those are the ideals of agile. But I have never seen any of them successfully done in the real world. Instead agile as implemented (which never resembles the ideal) just makes everything worse.
Re: Agile / Waterfall mix? (Score:5, Interesting)
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.
Knowledge (Score:2)
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 bl
Good vs bad Code (Score:2)
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 h
Yeah, I've got a suggestion (Score:2)
Quit RIDING MY ASS, Jim!
In my experience.... (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
Seems like a horrible and unusual experience. In a sane organization, getting fired would be a very extreme response to not participating in a single project. You will likely be transferred to something more to your liking. If it's your constant attitude, then yes you will have problems. But then how do you expect to work in a place if you can not make yourself useful?
Re: (Score:3)
If all they want you to do is code, then they want a code monkey, not a programmer. There may be a lack of jobs where you are, but I'd look around for better.
Re: (Score:3)
That's why you don't really say "No".
Assuming your boss isn't asking you to do something unethical or illegal, your job is to provide as much information so the best possible decision can be made. SO in this case you will be telling your boss (customer/$$$/etc) everything wrong with what they are telling you to do. If after all of that their decision doesn't agree with your data then it is their liability. You did your due diligence and should document it thoroughly and documentation means you're getting
And in other news... (Score:2)
Requirements, specifications and solutions (Score:2)
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 looki
Speed is not the point (Score:2)
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.
In other words (Score:2)
Don't hate the player, hate the game.
Trouble is, the game never changes.
Meetings (Score:2)
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.
Re: (Score:2)
Problem is tools... (Score:2)
... 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... [codinghorror.com]
Since most (non multi-core) code happens sequentially. To see this, imagine an extremely simple computer with only a few KB of
saying no is great, but.... (Score:3)
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.
Experiences as a manager... (Score:2)
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
Don't dis the process, embrace it. (Score:2)
Don't leave the core or logic behind (Score:3)
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.
Corporate Policies (Score:3)
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.
Definitely not universal (Score:2)
This just reminds me even more how much I love my job.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Then fix it.
You say that as if its possible.
Re: (Score:2)
Re: (Score:2)
Not a fan of agile, I take it. Thank you for that accurate perspective, made my whole day.
Re: (Score:3)
Scrums should be 15-20 minutes a day. Period. And they should be stand-ups. And they should only be used to unblock not for status.
Project status should be reported by the position of the cards on your board. You do Agile well and you don't need a daily or weekly status meeting for developers. If you are doing code reviews, you are evaluating code and progress at the same time.
If there is a weekly status meeting with product owners, the manager or scrum master should be attending and no one else. That
Re: (Score:2)
I learned Project Management in grad school from Ted Kozman [ultoday.com], and his guiding philosophy was the principle my peers and I codified as Kozman's Law:
If you fail to prepare to plan, plan to prepare to fail.
Re: (Score:2)
Sounds like a typical manager, everything more complicated than it needs to be in order to sound clever. My grade four teacher told us "prior planning prevents pretty poor performance." You could cut that down to "think first."
Re: (Score:3, Insightful)
Good lord, I could not agree more. From what I've learned in the last three companies I worked for that used agile, agile means that an ungodly amount of time is spent in meetings and constant, meaningless record-keeping. God, I hate agile. It gets in the way of doing good, timely work.
Re: (Score:2)
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 ...