tag:blogger.com,1999:blog-7533727264507128560.post8236721067993129570..comments2024-03-28T10:49:53.597-07:00Comments on Lessons Learned: The engineering manager's lamentErichttp://www.blogger.com/profile/12249063135381216090noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-7533727264507128560.post-55014020524320632642009-09-15T10:16:46.188-07:002009-09-15T10:16:46.188-07:00@anonymous
We do not live in a black and white wo...@anonymous<br /><br />We do not live in a black and white world.<br />Complexity is a rich set of understandings that need to be assimilated in part and whole. The intellectual capacity of the beholder introduces granularities of complexity.<br /><br />Secondly, I don't think I blamed the economic meltdown on agile development. OTOH, I do think there's a connection between macro business process requirements being so myopically and expediently defined at a granular level that the resulting macro process ignores both the risk and the consequence of such lightweight analysis.<br /><br />After all, the entangled nightmare we watched implode <i>was</i> a story that should have been factored in, no?Frank Krasickihttps://www.blogger.com/profile/01484416897999464357noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-75252874888234971512009-08-29T13:24:16.430-07:002009-08-29T13:24:16.430-07:00Excellent post Eric. I'm a die hard believer i...Excellent post Eric. I'm a die hard believer in TDD. Sometimes I find myself working on a project where unit tests weren't written let alone in a TDD fashion. The resulting code is such that it's very hard to add in tests. It seems that a project can get to a point where the "technical debt" is so high that the project is bankrupt meaning it would be "cheaper" to rewrite than try to add tests while you are chasing bugs. Of course it's hard to completely throw away code the company has invested in. I see big companies throw code away all the time but it seems harder for smaller companies to do it. <br /><br />Any advise on how the decision to rewrite may change for lean startups?jackcrewshttps://www.blogger.com/profile/06881349823384927826noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-77125677085674441872009-06-15T20:43:53.126-07:002009-06-15T20:43:53.126-07:00@The Caretaker, there is no such thing as more (or...@The Caretaker, there is no such thing as more (or less) complex; there is complex, and there is not complex.<br /><br />I'm sure we all agree the technology landscape has changed in the last 30 years, but are you blaming agile development for the global financial crisis? wow.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-53694265450308549352009-06-15T20:40:25.001-07:002009-06-15T20:40:25.001-07:00@Eric,
Is this post about Architecture? I define ...@Eric,<br /><br />Is this post about Architecture? I define Architecture (capital A) as "the advocacy for human values in a process" (not little a architecture, over-arching structural approach, just design-in-the-large). <br /><br />Cost and time are effectively absolutes (The Caretaker's high finance schenanigans and 20th century Physics aside). Quality is an abstraction of value, and value of service (or changes) is situated in human contexts. Value of comoddities is not situated in a human context (perhaps this is the source of the confusion) - the market determines a price for Grad A rice vs. Grade B rice (or whatever) just as it efficiently as it determines a price between Grade A rice and Gold - but quality/value of services are effectively orthoginal to cost and time, because different contexts have different value drivers.<br /><br />Actually, "the market" and "commodities" are just a way of saying "shared context", but that's just semantics...<br /><br />The story of the engineering manager is one of an Architectural challenge - positive value expectations in one context (e.g. new features please, suit) are conflicting limiting factors in another (e.g. less pain please, scruff). Most often conflicting value drivers are resolved with a ballanced compromise decision (either deliberately, or via some ecconomic method). E.g. as many features as possible and as much pain as is bearable.<br /><br />But sometimes an Architect finds a way to respond to challenge by redefining the process (re-aligning it to values) to fit the humans; instead of trading-off values against each other. That's value-creating, it's why they get to wear bow ties.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-7323311784315176032009-05-28T20:54:40.428-07:002009-05-28T20:54:40.428-07:00Not bad for an engineer.Not bad for an engineer.control valveshttp://www.meaincorporated.com/noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-79489014013315812009-04-03T07:19:00.000-07:002009-04-03T07:19:00.000-07:00Although I haven't read Crosby's book and I don't ...Although I haven't read Crosby's book and I don't doubt the veracity of his insights, I think the problem is far more complex these days.<BR/><BR/>In 1980, the transformation of business was largely a transition from manual processes to rudimentary computing solutions. This was the age of Alvin Toffler's 'Future Shock'. Computing was a closed society.<BR/><BR/>Today, the transformations are often from migrating all those rudimentary legacy systems into a technological windtunnel described by Ray Kurzweil in 'The Singularity is Near'.<BR/><BR/>It is not uncommon to be working on a project with a fixed budget of three to six months, a development window of 2-5 months, and ZERO wiggle room.<BR/><BR/>In indubitably, the project will be saddled with a set of business analysts whose richest experience with an advanced system has been to browse some web pages or order something online. *They* will consume, in one form of obfuscation or sheer ignorance, 90% of the time, resources, patience, and goodwill toward getting the project done. In their wake, will be a tortured/retarded design, techno-tribal one-upsmanship, and a desperate to-hell-with-any-and-all-best-practices, get-the-damned-thing-out-the-door stampede.<BR/><BR/>One need look no further than the hedge-fund calamity as a shining example of systems and shysters presumably generating enormous wealth. I would ask fellow professionals what these systems were doing to make this kind of thing possible - no one had any idea except to believe that these systems were so sophisticated at playing/manipulating the market that they were the ones consuming all or most of Wall Street's magic profits. In other words, these systems were built fast and cheap to establish a set of smoke and mirrors no one would ever be able to penetrate quickly enough to realize or abate the damage. And no one got paid who asked questions - outsourcing provide a perfect petri dish for complacency, conformity, and duplicity.<BR/><BR/>In that stew of seemingly limitless wealth creation that no one dared question, a cult of 'extreme' and 'agile' practices flourished that at face value asserted that businesses "didn't need any stinkin" design more complex than that that immediately satisfied the gratification urge.<BR/><BR/>IMO, this sharp right turn in our industry toward compromising the integrity of process [where quality matters] toward eliminating the cost of integrity has both incapacitated project development AND created and enabled a shadow profession to corrupt the profession.<BR/><BR/>Our profession is in trouble. It is as if the staffing and management of projects is run by international syndicates more interested in controlling job territories than in assembling vital, dynamic teams who are empowered to succeed.<BR/><BR/>- krasickiFrank Krasickihttps://www.blogger.com/profile/01484416897999464357noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-89547364127432842682009-04-02T06:24:00.000-07:002009-04-02T06:24:00.000-07:00Philip B. Crosby made this argument in his book "Q...Philip B. Crosby made this argument in his book "Quality Is Free: The Art of Making Quality Certain" (Mentor, 1980)Mark Herschberghttp://www.linkedin.com/in/hersheynoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-44277049043893681852008-12-20T09:44:00.000-08:002008-12-20T09:44:00.000-08:00@Caretaer, ti spoint of yours makes a lot of sense...@Caretaer, ti spoint of yours makes a lot of sense<BR/><I>Too often developers don't start with requirements per se but fuzzy wish lists that creep specifications into *how* to implement the thing.</I><BR/><BR/>I often see PMs walking up to engineers saying "let us add another column to this db that will help me get info on foobar" and engineers saying "that is a multi valued attribte and os we need ot create a new table with references". Granted that this is an extreme case but a description of the requirements purely in terms of implementation causes a lot of trouble.Anomalizerhttps://www.blogger.com/profile/08059667562834749208noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-42650605095423193422008-10-22T22:27:00.000-07:002008-10-22T22:27:00.000-07:00@Eric On Startups:To me the problem is the concept...@Eric On Startups:<BR/><BR/>To me the problem is the concept of *detailed* specs. In far too many companies, massaging the same frikkin' paragraph for a month is considered requirements gathering.<BR/><BR/>The only details an engineer might need is: Create a form with these fields, a, b, c.<BR/><BR/>a is name, b is address, and c is tax percentage.<BR/><BR/>Instead the engineer gets a twenty page document that took six months to cut and paste together containing the signatures of PMs, VPs, foreign dignitaries and gatekeeper of the treasury.<BR/><BR/>And the 20 page thingy is more confusing than the sentence of what's sufficient.<BR/><BR/>@situmam On triple constraints.<BR/><BR/>You're mixing up development concepts with project management concepts. These pairs of triplets are orthogonal not alike.<BR/><BR/>You are confusing the label for the thing.<BR/><BR/>For example, a PM time unit is far different from a development one. A project usually has an absolute duration and budget whereas the time and money dedicated to development within the project is where the tradeoffs are made.<BR/><BR/>And projects don't have quality per se. They have deliverables that have quality constraints.<BR/><BR/>The PMs relationship to quality is a step removed from the development team that is directly affected by the quality every day.Frank Krasickihttps://www.blogger.com/profile/01484416897999464357noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-54503442023632217362008-10-22T18:34:00.000-07:002008-10-22T18:34:00.000-07:00The time, money and quality dimensions are referre...The time, money and quality dimensions are referred to, in the project management world, as the triple constraints. Any serious PM has to have a healhty and practical understanding of these trio.<BR/><BR/>In PM land, we call them Work (money), Duration (time) and, utilization (scope). Some people refer to scope as effectiveness, Units, availability or quality.<BR/><BR/>I think this blog clearly shows that having a PM that can influence development and management teams can have a tremendous positive impact on the project's success and ultimately the company as well.situmam1https://www.blogger.com/profile/01590919360924341740noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-4387597905681773932008-10-22T16:48:00.000-07:002008-10-22T16:48:00.000-07:00@peter - on the silo issue, you might want to take...@peter - on the silo issue, you might want to take a look at the companion piece to this one <A HREF="http://startuplessonslearned.blogspot.com/2008/10/product-managers-lament.html" REL="nofollow">The product manager's lament</A>. I strongly believe building cross-functional teams.<BR/><BR/>One thing I will add, though, that is unique to the startup experience: writing a detailed spec is usually impossible. The reason is that, unlike your traditional agile situation, you don't know what problem you're trying to solve. All you have is a set of hypotheses (which should be written down). Each iteration should help you validate or refute some of those hypotheses. But the product at the end of several iterations generally bears little resemblance to what was originally "required."Erichttps://www.blogger.com/profile/12249063135381216090noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-76813235912332240762008-10-22T14:31:00.000-07:002008-10-22T14:31:00.000-07:00I'm keen on the two-kinds-of-bugs thing. It might...I'm keen on the two-kinds-of-bugs thing. It might be more precise to categorize them of two kinds of flaws: flaws in implementation, and flaws in design. Implementation flaws are "defects" as you define them, and I agree that you really don't want any defects. Flaws in design as a different story, and shouldn't be treated the same way; a user can live with software that doesn't have one of the features advertised, but he can't live with software where a feature sometimes does one thing, and sometimes another.Matt Waggonerhttps://www.blogger.com/profile/17109706568753103025noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-27254673798732516962008-10-22T14:10:00.000-07:002008-10-22T14:10:00.000-07:00Software Eng. here who spent a couple years in Eng...Software Eng. here who spent a couple years in Eng. Mgt. then five years in Product Mgt. I also have to include this caveat: we weren't purely a software company - we built telecom network devices, hw and sw. <BR/><BR/>Keeping in mind that caveat, in our world the biggest factor in total project ROI was time to market. Also, our stuff was pretty much useless to our customers if it wasn't full featured AND reliable. Of course, the sales folks had new features as their #1 priority. Top management's #1 was usually ROI. Engineering's #1 of course, was quality. What a freaking mess. Everybody was constantly mad at everybody and finger pointing took both hands. I spent more money on gin... <BR/><BR/>I/we came up with various "fixes" but nothing worked, not for long anyway. There was an underlying problem which we weren't addressing. I think your solution misses the underlying problem as well. <BR/><BR/>We ended up rethinking our entire product development process, top to bottom, start to finish. It was painful for a lot of people. But the results were excellent - customer satisfaction, sales, profits, quality, attitudes all improved dramatically. <BR/><BR/>The major change was never starting any project without sales, marketing, manufacturing, field support, purchasing, etc. ALL signing off on the (detailed, specific, traceable and testable) requirements and schedule. For many projects, customer approval and sign off was required as well. Second was not changing the requirements without full sign-off. <BR/><BR/>Those two process improvements alone made a huge difference. Most of the other processs changes - mandatory design reviews (prelimninary, critical, etc), - documenting all our procedures, and so on - were to support those two factors. <BR/><BR/>Summing up my $0.03, eliminating the "silo effect" where people can throw things over the wall by bringing people from every business function into the development process from the start is the way to permannetly address the underlying problem.Pupienus Maximushttps://www.blogger.com/profile/17834551827088880423noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-23878106686347293992008-10-22T12:07:00.000-07:002008-10-22T12:07:00.000-07:00*All* of the factors involved in delivering softwa...*All* of the factors involved in delivering software are affected by starting with baseline requirements that are constrained to what the system should do and the process artifacts desired (say 5 forms reading and writing a database store).<BR/><BR/>Too often developers don't start with requirements per se but fuzzy wish lists that creep specifications into *how* to implement the thing.<BR/><BR/>Now that changes the relationship of what is actually required to what is desired in a business fantasy fest.<BR/><BR/>All the commitment of time, money, and quality angst can never overcome the fishing expedition effect of bad requirements.<BR/><BR/>Excepting for cosmically co-incidental success stories, the fuzzy requirement stuff never congeals as a holistic engineering exercise. More likely these systems resemble a pastiche of Rube Goldberg components that are never quite logically symmetric.<BR/><BR/>The choices you make are inconsequential unless you start with a clear idea of sufficiency.Frank Krasickihttps://www.blogger.com/profile/01484416897999464357noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-48288344275782398612008-10-21T20:41:00.000-07:002008-10-21T20:41:00.000-07:00@larry - well said. I think where we get into trou...@larry - well said. I think where we get into trouble is we have many definitions of quality. If we take the broadest possible interpretation, and we insist on letting engineers unilaterally decide that they can't ship without "quality," we could get in trouble.Erichttps://www.blogger.com/profile/12249063135381216090noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-8215408611548052972008-10-21T20:40:00.000-07:002008-10-21T20:40:00.000-07:00@chris - I couldn't agree more. Anything that does...@chris - I couldn't agree more. Anything that doesn't contribute to figuring out what customers want is waste, even if it's a cool feature.Erichttps://www.blogger.com/profile/12249063135381216090noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-66905956639669266482008-10-21T16:54:00.000-07:002008-10-21T16:54:00.000-07:00Thanks for the post. I was a manager for 7+ years...Thanks for the post. I was a manager for 7+ years.<BR/><BR/>In my view, it's not time, quality, or money. It's always: fixed time, chase quality, and money is tight.<BR/><BR/>My solution has been to change the question to: time or features. Quality is never negotiable to me.<BR/><BR/>That's a more realistic approach. A deadline is either rock solid or it is flexible. When you are hitting the limit, it's best to prioritize features and focus on the most important ones.Larry Freemanhttps://www.blogger.com/profile/06906614246430481533noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-4284946258392380322008-10-21T16:33:00.000-07:002008-10-21T16:33:00.000-07:00There is one assumption in your (in general well t...There is one assumption in your (in general well thought-out) post that is problematic.<BR/><BR/>I would posit that what matters to customers is NOT features -- and that in fact this assumption is a large cause of much of the pain you're describing.chrishttps://www.blogger.com/profile/07259964812670851159noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-2114241681341710792008-10-20T23:40:00.000-07:002008-10-20T23:40:00.000-07:00@nathan, I know it sounds crazy, and I hope to tal...@nathan, I know it sounds crazy, and I hope to talk about it in detail in a future post. I do recommend it, but not for its own sake. It requires two things:<BR/><BR/>1. a completely automated and easy to setup development environment. Debugging problems with the dev environment itself is a common form of waste that this practice eliminates.<BR/><BR/>2. a robust set of defense mechanisms against a bad change making it to production. A new employee is more likely to make a mistake than an experienced one, but everyone makes mistakes. If you have confidence that your tools make it easy to understand the impact of a change, make it easy to prevent a bad change from making it to production, and make it easy to recover from a bad change that gets through your defenses - then how much damage can a new employee cause?<BR/><BR/>Of course, we wouldn't have a new employee write a huge new feature on their first day - usually we'd start with a simple cosmetic change or bug fix. But that kept the pressure on us to make sure we were keeping our tools simple and easy to use.Erichttps://www.blogger.com/profile/12249063135381216090noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-47362898736824785892008-10-20T23:32:00.000-07:002008-10-20T23:32:00.000-07:00Eric: you say "new engineers at IMVU were always r...Eric: you say "new engineers at IMVU were always required to ship something to customers on their first or second day".<BR/><BR/>This sounds a little crazy to me. Would you recommend this practice for other companies?Unknownhttps://www.blogger.com/profile/14694780517877199678noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-53511574103119401322008-10-20T22:36:00.000-07:002008-10-20T22:36:00.000-07:00Great stuff! A couple thoughts:ONETime, quality, a...Great stuff! A couple thoughts:<BR/><BR/>ONE<BR/><BR/>Time, quality, and money are three dimensions. <BR/><BR/>Scope is the fourth. Everyone forgets about scope. Reducing scope lets you deliver on the first three dimensions. Not fixing bugs is a type of scope reduction but there are many other ways to reduce scope.<BR/><BR/>Reducing scope is the theoretical basis for the conventional wisdom that startups should do "one thing really well."<BR/><BR/>TWO<BR/><BR/>See page 199 of <A HREF="http://www.amazon.com/gp/product/0321437381?ie=UTF8&tag=httpventureco-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321437381" REL="nofollow">Poppendieck and Poppendieck's new(er) book</A> for a finer analysis of defects and bugs:<BR/><BR/>Unit tests prove that the code does what the developer's want it to do, i.e. there are no defects.<BR/><BR/>Acceptance tests determine that the code does what the customer wants it to do, i.e. the features are sufficient.<BR/><BR/>Exploratory tests (traditional QA) determine that the code doesn't do what the customer and engineers don't want it to do, i.e. there are no bugs.Nivihttps://www.blogger.com/profile/14820480125416930987noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-88162994213105097902008-10-20T21:34:00.000-07:002008-10-20T21:34:00.000-07:00Laughed out loud at this post, because it so appli...Laughed out loud at this post, because it so applicable to what I'm doing in my new gig. <BR/><BR/>Our team's goal right now is increasing our system's scalability. What is the first thing I'm having the team do? Write and automate tests to reduce the defects preventing us from getting a successful load test run on each attempt. Why? Our quality and engineering services folks were burning more hours patching over intermittent failures in our load test environment than our development engineers were improving the scalability.<BR/><BR/>It can be a little awkward to ask a team used to code-and-fix (and-fix, and-fix) to stop muscling out code and instead stop and fix the defects preventing success. But, it is so worth it.Chris Hondlhttps://www.blogger.com/profile/03282556433049642012noreply@blogger.com