Started a base platform for us to play with...vocals! Being a huge singer myself, I don't mind trying - really, it's the topic to choose. I think it'll have to continue the "absurdist" theme.
The song so far is short, unmastered, and composed entirely on the road with just clips from the web(!) This little laptop is a 1-pound amateur studio, and it's fun!
Saturday, August 19, 2006
Tuesday, August 15, 2006
Vacation - Part 2
Some great photos from our South America tour. There are over 5000 photos from this trip, and so many stories and events that we cannot begin to wrap our arms around it all. Suffice it to say that our trip was excellent and these snapshots are a quick skip through some of the places. We would also like to introduce Cristian and Vanessa, our two favorite people on the whole continent!
A Mapuche Indian woman gives us a blessing of good fortune using young eucalyptus leaves. She approved of Hanmi and I picking up Cristian and Vanessa hitchhiking and all of us traveling together. By keeping the blessed leaves in our wallets, "money would soon replace it." I can say that the leaf dried out and fell apart, but everyone who got my bills after that got some sweet-smelling money. Overall, we did feel blessed with a wealth of new experiences.
Our 2-room cabin, complete with wood stove and running water. This was our home for 3 days of the trip. It was both beautiful and sparse.
In the tiny fishing town of Bucalemu, Hanmi and I strolled along the promenade, soaking up the sun and the quaint images.
Vanessa, Cristian, Hanmi and I practice some slacklining with a climber friend's gear. They were passing through for the night and decided to set it up on the trees. It was tough!
Sunset in the busy town of Pucón. This was a waypoint for a lot of tourists, but it had some nice restaurants and we restocked our camping supplies. Very much like a Chilean version of Jackson, Wyoming. It was too touristy for us to stay overnight, though.
Some beautiful mountains peaks (we have dozens of shots of all kinds of peaks) along the border between Chile and Argentina.
Swimming in the "termas" (hot springs) that warm the snow melt from Mt. Villarrica, several miles away. Portions of the valley held natural steaming-hot pools, and this one was just captured water from the rushing river, built from logs. Very relaxing!
Vanessa's pet tarantula. Hanmi didn't mind goofing around with it. I almost fainted just holding it. Not a fan of spiders on my skin.
Some beautiful relief work done along an old, almost abandoned shipbuilding town in Buenos Aires
Relaxing after a cold swim on one of the nights of our Chilean adventure. Cristian and Vanessa shared their favorite foods with us (hot dogs!), and we tried to show them how to cook potatoes in the fire.
Some colorful and fun bike-based merchants in the farmers market in Chillán, along the route between Santiago and Pucon.
The four adventurers return back to Santiago after a long drive. Cristian and Vanessa's families were both very nice, hosting us and making us feel very welcome. We will be visiting them again in 2007, I think!
A Mapuche Indian woman gives us a blessing of good fortune using young eucalyptus leaves. She approved of Hanmi and I picking up Cristian and Vanessa hitchhiking and all of us traveling together. By keeping the blessed leaves in our wallets, "money would soon replace it." I can say that the leaf dried out and fell apart, but everyone who got my bills after that got some sweet-smelling money. Overall, we did feel blessed with a wealth of new experiences.
Our 2-room cabin, complete with wood stove and running water. This was our home for 3 days of the trip. It was both beautiful and sparse.
In the tiny fishing town of Bucalemu, Hanmi and I strolled along the promenade, soaking up the sun and the quaint images.
Vanessa, Cristian, Hanmi and I practice some slacklining with a climber friend's gear. They were passing through for the night and decided to set it up on the trees. It was tough!
Sunset in the busy town of Pucón. This was a waypoint for a lot of tourists, but it had some nice restaurants and we restocked our camping supplies. Very much like a Chilean version of Jackson, Wyoming. It was too touristy for us to stay overnight, though.
Some beautiful mountains peaks (we have dozens of shots of all kinds of peaks) along the border between Chile and Argentina.
Swimming in the "termas" (hot springs) that warm the snow melt from Mt. Villarrica, several miles away. Portions of the valley held natural steaming-hot pools, and this one was just captured water from the rushing river, built from logs. Very relaxing!
Vanessa's pet tarantula. Hanmi didn't mind goofing around with it. I almost fainted just holding it. Not a fan of spiders on my skin.
Some beautiful relief work done along an old, almost abandoned shipbuilding town in Buenos Aires
Relaxing after a cold swim on one of the nights of our Chilean adventure. Cristian and Vanessa shared their favorite foods with us (hot dogs!), and we tried to show them how to cook potatoes in the fire.
Some colorful and fun bike-based merchants in the farmers market in Chillán, along the route between Santiago and Pucon.
The four adventurers return back to Santiago after a long drive. Cristian and Vanessa's families were both very nice, hosting us and making us feel very welcome. We will be visiting them again in 2007, I think!
Thursday, August 10, 2006
Staring at code from across the sea
Offshore programming seems to be a hot issue in the past few years. Well, I'm on my third placement as a software engineer reviewing the output of code written from India. I can't generalize the entire industry from the evidence I've seen, but in this short experience there are some depressing patterns.
You can't ask for a piece of technology without clear requirements, many of which are only flushed out as development starts to present a partly-complete product. "Oh, I want something like this, but more of..." is a common sentiment of the requester. So, iteration and involvement are key concepts in this endeavor. The problem is, if you do this too late in the process, you have to pay for the un-building of some parts to accommodate your changes. Ok, so this much is obvious. Already, one can see that putting a development team far away from the customer would present a hurdle to a smooth flow of communication.
The programming industry has two levels: "SELL/DELIVER!" - The personality who wants to focus on getting the requests met quickly and within budget. Then there's "ANALYZE/ADVISE!" - The personality seeks to focus on flushing out all the details so that the request is clear and potential issues are resolved before its too late.
Both of these are in balance the entire way. Too much on either side and problems arise: SELL/DELIVER will release a product that does everything initially asked, but it's not very dynamic. The product needs a lot of effort to adjust to the real-world, which is always in flux. "We want to add to this..." can be a death-knell for a product that hasn't thought about so-called "Flex Points." Flex Points are the software equivalent of "ways to accommodating change." If you built a swing set, you wouldn't weld the chains to the seat, because the chains may need to be lengthened or shortened at some point. Well, without a flex point, a change's effort is higher - this means expensive. This lack of flexibility can become apparent even before the project is released - which early on is a relatively better find, since 1 delay to install a flex point is better than years of expensive changes.
Conversely, too much focus on the ANALYZE/ADVISE can have other adverse effects: First, you may have to start defending longer and longer periods of design and discussion about "what are we going to do?" without yet delivering product parts (this criticism is due in part to the miss-classification of analysis as "non-work" by some of the other camp). One ends up with a large amount of descriptive information about a project. For the most part, many folks view this as a Good Thing. However, documentation is sometimes unnecessary: only what is read later or presented to the customer for discussion is useful. The rest is bloat. Also if the construction team is the same as the analysis team, documenting the entire system is usually unnecessary, since they will soon be iterating prototypes and early releases to the client. The formalization of the design documents is best used when handing the design to another team - like an offshore team. At that point, a whole new set of risks arise.
Similar to the value of Design Documents that only have value if used, the Flex Points built into software are only valuable once *used*. Before that, they are effort (investment) in anticipation of change. One must draw a line between how much change you will accommodate in an initial design, and how much work an enhancement may entail. There are advantages to each - one makes work analogous to "entering a record in the table" or "changing a value in the profile" versus "rework the logic and recompile." For example, if you anticipate a future of your swing set that may allow for a tree house on top of it, you invest a lot of effort in the construction of the base level. If your guess is wrong and no tree house is ever needed, that cost was needless. One shouldn't speculate on the market when building in Flex Points. Instead, you leave those changes up to another release, which requires not Flex Points, but Modular Design. Modular Design suggests that you can hang the swings from another, different frame in the future without a lot of effort, and save the design of a 2-story swing set with tree house for another project. In software, this is essentially building-in a low coupling between components, anticipating that entire components, while not flexible enough initially, can be rewritten and then replace the prior component without disturbing the entire system.
As an aside, this is why XML as a communication encoding gained popularity. Each component in the application can read when it needs from the information flowing around, and ignore other parts. XML alone doesn't make this happen, but the standard tools for using XML-encoded data facilitate this easily. Other components in the system can ignore the new data a future releases start adding to the data, until individual replacement components can take advantage of such data. Meanwhile, existing components need not be touched, saving a large part of the testing and code management costs.
In an offshore project, you typically have a team show up at your doorstep to flush out a design. If they are going to write it, one suspects you no longer need any software experts in-house to help. However, this is the mistake I've been hired to clean up time and again: The software Delivered but severely lacked on both the Flex Points and the Modular Design approaches. The team analyzed the problem to solve, but never seemed to ask questions about what the customer envisioned in their future, and never presented a menu of trade-offs of flexibility/cost to the customer.
Thus, at some point after the birthing process of the project (a big deal), the perceived "win" degrades. The market or business needs hit the software and it cannot change easily. Each programmer diving into the product tells the customer "this wasn't written to accommodate what you're asking" and the customer is left frustrated in paying more for changes than they expected. Changing the system not longer mimics a replacement of parts wired lightly together; it resembles delicate surgery.
Note, personally I tell customers 2 things when starting to design a system: (1) The balance of what any team, customer or consultant, can foresee is limited. One must focus on productive concepts and modular design that can grow easily. Change will always cost something, but minimizing it is in everyone's best interest. (2) The initial analysis has two parts: the business problem we're solving and the technical description of the Flex Points and Modules. This mean the analysis make take a bit longer than expected, but it reduces the risk of making a poor decision.
Thankfully, software engineering principles of the last five years have taken this into account. Multiple technology layers have arisen that allow for Flex Points and Modular Design to be easily incorporated into a platform. The Object-Oriented drive of software in the prior 15 years has matured into a distributed component-oriented design. Web Services, XML, object frameworks, and a multitude of standard toolsets from large vendors make this easy. The only drawback to a business is training their programmers to understanding and using these principles. Younger programmers may learn this in school, but older programmers usually know the business data better. Solution Space (modern design) versus Problem Space (business data relationships). Both must be merged and used together.
This again comes back to a drawback of offshore programming: The Business Data relationships have to be completely flushed out and communicated clearly to a team that more-often-than-not doesn't understand the client's market. Now the skills of the Business Analyst comes into play, and low skills here can spell disaster when the Offshore team assumes relationships about the data which later prove to be false. Instead, using in-house developers or at least market-aware consultants allow the "right questions to be asked" as managers are fond of saying.
Given my experience, a business should prioritize the acquisition of software in tiers:
1:
If the issue is market-wide and not a custom need and solved with a common tool – use one! One doesn't usually see companies writing their own Email clients, for example. The commodization of tools such as those is mature and sufficiently flexible. Some tools allow for significant customization, which can encompass the usage pattern of the customer ("we need extra fields in our email..." for example). For highly dynamic requirements, perhaps a large-vendor solution suffices (Lotus Notes communication platform), but one must start to examine why a customer needs such a level of dynamics in a common tool area. Continuing the example, this would be when a customer demands a custom email tool because their needs are beyond market tools - I begin to ask "Are you asking for features in the wrong part of the information flow?" Perhaps a combination of tools or another path accommodates the request. Technology knowledge can trump a savvy Business Analyst here, who sees an all-in-one tool when really a set of of-the-shelf tools integrated elegantly would suffice.
2:
If the business need is truly custom and dynamic, then writing a tool is probably necessary. Using any in-house developers is almost always a better investment, all other factors unchanged. Low morale, high turnover, and other issues of a workforce can make programmer training seem like a waste (indeed, training is doubly expensive, since more knowledgeable programmers can compete in a more expensive market for wages). But for a team that actually enjoys creating great solutions, an interesting project that provides real value to the business is always a win-win between programmer and business. For a business the ROI of highly skilled programmers can be realized over several projects. This implies a need for standardization on the solutions platforms. Managers that demand or suggest diverse platforms, and thus diverse skill sets, usually end up juggling too many workforce skills to know their team well. Consolidation on a robust platform is an easy bet.
3:
Bringing in help to augment a team can be beneficial. One note on that: Sequestering contractors away from the salaried folks (due to perceived secrecy or other politics) only ends up preventing the contractors needed skills from migrating to the people who will be maintaining the system long-term. I've seen businesses treat contractors like peasants, uninvited from most meetings and such - but then they are trusted to provide a much-needed skill and deal with some of the most delicate business data. This resulted in disaster when the contractor left, since a new one with the same skills had to immediately take their place. Although it benefits a contractor to be constantly in the "savior" position (it's quite lucrative!), a true consultant advises a business to take over the system entirely - training the team as the system is built. So, contractors are best used in pairs or teams.
4:
Lastly, as much as I've argued against remote development, it can be used constructively. I would advise businesses to allow their development team to break a solution into modules, allowing the remote team to deliver the modules piecemeal, and have the in-house team integrate them. This allows for the guidance on standards and the quality of the remote team to be reviewed in an iterative manner. Remember, this still means involvement of the local team to a large degree. They are designing the unit tests for the modules, which are written and run by the remote team. The local team is also reviewing the code of the modules. Obviously, they are performing the system testing.
Overall, there’s no such thing as a Done System. The closer software is to aiding in businesses processes, the more dynamic and maintainable it must be. The skills to manipulate it must be common in the market and familiar to the in-house developers. Training, paired with direct usage of the new skills on in-house projects, is a necessary part of keeping a team happy. This does not mean “adopting new technologies” so much as “going deep” on the decided platforms already in-house.
“Turning the ship” of a company can be frustrating and involving and lot of pontificating and preaching, but if the effects of poor decisions can be predicted, a business will notice. If you see your client or company making an obvious mistake in your eyes, speak up and be ready to listen. Papers such as this aren’t the only place wisdom can be imparted.
You can't ask for a piece of technology without clear requirements, many of which are only flushed out as development starts to present a partly-complete product. "Oh, I want something like this, but more of..." is a common sentiment of the requester. So, iteration and involvement are key concepts in this endeavor. The problem is, if you do this too late in the process, you have to pay for the un-building of some parts to accommodate your changes. Ok, so this much is obvious. Already, one can see that putting a development team far away from the customer would present a hurdle to a smooth flow of communication.
The programming industry has two levels: "SELL/DELIVER!" - The personality who wants to focus on getting the requests met quickly and within budget. Then there's "ANALYZE/ADVISE!" - The personality seeks to focus on flushing out all the details so that the request is clear and potential issues are resolved before its too late.
Both of these are in balance the entire way. Too much on either side and problems arise: SELL/DELIVER will release a product that does everything initially asked, but it's not very dynamic. The product needs a lot of effort to adjust to the real-world, which is always in flux. "We want to add to this..." can be a death-knell for a product that hasn't thought about so-called "Flex Points." Flex Points are the software equivalent of "ways to accommodating change." If you built a swing set, you wouldn't weld the chains to the seat, because the chains may need to be lengthened or shortened at some point. Well, without a flex point, a change's effort is higher - this means expensive. This lack of flexibility can become apparent even before the project is released - which early on is a relatively better find, since 1 delay to install a flex point is better than years of expensive changes.
Conversely, too much focus on the ANALYZE/ADVISE can have other adverse effects: First, you may have to start defending longer and longer periods of design and discussion about "what are we going to do?" without yet delivering product parts (this criticism is due in part to the miss-classification of analysis as "non-work" by some of the other camp). One ends up with a large amount of descriptive information about a project. For the most part, many folks view this as a Good Thing. However, documentation is sometimes unnecessary: only what is read later or presented to the customer for discussion is useful. The rest is bloat. Also if the construction team is the same as the analysis team, documenting the entire system is usually unnecessary, since they will soon be iterating prototypes and early releases to the client. The formalization of the design documents is best used when handing the design to another team - like an offshore team. At that point, a whole new set of risks arise.
Similar to the value of Design Documents that only have value if used, the Flex Points built into software are only valuable once *used*. Before that, they are effort (investment) in anticipation of change. One must draw a line between how much change you will accommodate in an initial design, and how much work an enhancement may entail. There are advantages to each - one makes work analogous to "entering a record in the table" or "changing a value in the profile" versus "rework the logic and recompile." For example, if you anticipate a future of your swing set that may allow for a tree house on top of it, you invest a lot of effort in the construction of the base level. If your guess is wrong and no tree house is ever needed, that cost was needless. One shouldn't speculate on the market when building in Flex Points. Instead, you leave those changes up to another release, which requires not Flex Points, but Modular Design. Modular Design suggests that you can hang the swings from another, different frame in the future without a lot of effort, and save the design of a 2-story swing set with tree house for another project. In software, this is essentially building-in a low coupling between components, anticipating that entire components, while not flexible enough initially, can be rewritten and then replace the prior component without disturbing the entire system.
As an aside, this is why XML as a communication encoding gained popularity. Each component in the application can read when it needs from the information flowing around, and ignore other parts. XML alone doesn't make this happen, but the standard tools for using XML-encoded data facilitate this easily. Other components in the system can ignore the new data a future releases start adding to the data, until individual replacement components can take advantage of such data. Meanwhile, existing components need not be touched, saving a large part of the testing and code management costs.
In an offshore project, you typically have a team show up at your doorstep to flush out a design. If they are going to write it, one suspects you no longer need any software experts in-house to help. However, this is the mistake I've been hired to clean up time and again: The software Delivered but severely lacked on both the Flex Points and the Modular Design approaches. The team analyzed the problem to solve, but never seemed to ask questions about what the customer envisioned in their future, and never presented a menu of trade-offs of flexibility/cost to the customer.
Thus, at some point after the birthing process of the project (a big deal), the perceived "win" degrades. The market or business needs hit the software and it cannot change easily. Each programmer diving into the product tells the customer "this wasn't written to accommodate what you're asking" and the customer is left frustrated in paying more for changes than they expected. Changing the system not longer mimics a replacement of parts wired lightly together; it resembles delicate surgery.
Note, personally I tell customers 2 things when starting to design a system: (1) The balance of what any team, customer or consultant, can foresee is limited. One must focus on productive concepts and modular design that can grow easily. Change will always cost something, but minimizing it is in everyone's best interest. (2) The initial analysis has two parts: the business problem we're solving and the technical description of the Flex Points and Modules. This mean the analysis make take a bit longer than expected, but it reduces the risk of making a poor decision.
Thankfully, software engineering principles of the last five years have taken this into account. Multiple technology layers have arisen that allow for Flex Points and Modular Design to be easily incorporated into a platform. The Object-Oriented drive of software in the prior 15 years has matured into a distributed component-oriented design. Web Services, XML, object frameworks, and a multitude of standard toolsets from large vendors make this easy. The only drawback to a business is training their programmers to understanding and using these principles. Younger programmers may learn this in school, but older programmers usually know the business data better. Solution Space (modern design) versus Problem Space (business data relationships). Both must be merged and used together.
This again comes back to a drawback of offshore programming: The Business Data relationships have to be completely flushed out and communicated clearly to a team that more-often-than-not doesn't understand the client's market. Now the skills of the Business Analyst comes into play, and low skills here can spell disaster when the Offshore team assumes relationships about the data which later prove to be false. Instead, using in-house developers or at least market-aware consultants allow the "right questions to be asked" as managers are fond of saying.
Given my experience, a business should prioritize the acquisition of software in tiers:
1:
If the issue is market-wide and not a custom need and solved with a common tool – use one! One doesn't usually see companies writing their own Email clients, for example. The commodization of tools such as those is mature and sufficiently flexible. Some tools allow for significant customization, which can encompass the usage pattern of the customer ("we need extra fields in our email..." for example). For highly dynamic requirements, perhaps a large-vendor solution suffices (Lotus Notes communication platform), but one must start to examine why a customer needs such a level of dynamics in a common tool area. Continuing the example, this would be when a customer demands a custom email tool because their needs are beyond market tools - I begin to ask "Are you asking for features in the wrong part of the information flow?" Perhaps a combination of tools or another path accommodates the request. Technology knowledge can trump a savvy Business Analyst here, who sees an all-in-one tool when really a set of of-the-shelf tools integrated elegantly would suffice.
2:
If the business need is truly custom and dynamic, then writing a tool is probably necessary. Using any in-house developers is almost always a better investment, all other factors unchanged. Low morale, high turnover, and other issues of a workforce can make programmer training seem like a waste (indeed, training is doubly expensive, since more knowledgeable programmers can compete in a more expensive market for wages). But for a team that actually enjoys creating great solutions, an interesting project that provides real value to the business is always a win-win between programmer and business. For a business the ROI of highly skilled programmers can be realized over several projects. This implies a need for standardization on the solutions platforms. Managers that demand or suggest diverse platforms, and thus diverse skill sets, usually end up juggling too many workforce skills to know their team well. Consolidation on a robust platform is an easy bet.
3:
Bringing in help to augment a team can be beneficial. One note on that: Sequestering contractors away from the salaried folks (due to perceived secrecy or other politics) only ends up preventing the contractors needed skills from migrating to the people who will be maintaining the system long-term. I've seen businesses treat contractors like peasants, uninvited from most meetings and such - but then they are trusted to provide a much-needed skill and deal with some of the most delicate business data. This resulted in disaster when the contractor left, since a new one with the same skills had to immediately take their place. Although it benefits a contractor to be constantly in the "savior" position (it's quite lucrative!), a true consultant advises a business to take over the system entirely - training the team as the system is built. So, contractors are best used in pairs or teams.
4:
Lastly, as much as I've argued against remote development, it can be used constructively. I would advise businesses to allow their development team to break a solution into modules, allowing the remote team to deliver the modules piecemeal, and have the in-house team integrate them. This allows for the guidance on standards and the quality of the remote team to be reviewed in an iterative manner. Remember, this still means involvement of the local team to a large degree. They are designing the unit tests for the modules, which are written and run by the remote team. The local team is also reviewing the code of the modules. Obviously, they are performing the system testing.
Overall, there’s no such thing as a Done System. The closer software is to aiding in businesses processes, the more dynamic and maintainable it must be. The skills to manipulate it must be common in the market and familiar to the in-house developers. Training, paired with direct usage of the new skills on in-house projects, is a necessary part of keeping a team happy. This does not mean “adopting new technologies” so much as “going deep” on the decided platforms already in-house.
“Turning the ship” of a company can be frustrating and involving and lot of pontificating and preaching, but if the effects of poor decisions can be predicted, a business will notice. If you see your client or company making an obvious mistake in your eyes, speak up and be ready to listen. Papers such as this aren’t the only place wisdom can be imparted.
Friday, July 14, 2006
Escape
After entering the funhouse in Aug 2005, I realized the warnings were true: "Do Not Challenge The Programmer" was said to me repeatedly. Here's the story of what I learned at a failing startup in the past year.
It began as an exciting departure from a few years of corporate-job software-guy doldrums. The surroundings were getting less and less exciting, and the folks I was developing with didn't want to excel at their technical expertise; they wanted traffic to go away to/from job and the 3% raise to land on them. Exciting as watching dogs poop.
So I jumped, ready for the consulting world. Except a funny thing happened along the way. I ran into some friends that were in a startup, and wanted to try and make it succeed. They were working in a neat concept and needed more help. The money was right, so I entered as full-time.
Well, one trip through the 400,000+ lines of code (for 40 screens) there gave me food for thought. It was written by someone seemingly out of touch with how client-server software is written for the past 10 years. Custom code for needless tools, buggy designs that poorly mimic things you get out of the box, etc. I took it as a challenge; the gauntlet was thrown! I was going to introduce a world of new modern designs, and turn the codebase into a humming, smaller, porche-engine of strength. Or so I thought.
"Um, who wrote all of this?" I asked. Several conversations starting like this are best condensed as:
"Oh, well GB." [name withheld to protect the crazy]
"GB? THE GB? The GB who is now CEO?"
"Yep."
Now for a company of 17 people this isn't rare. Plenty of software people get a fun idea, write it in their basement for a few years and then try to build a little company around it. However, this person was performing two roles actively: Suited CEO and investment cheerleader, and midnight-frantic programmer guy. I can't say for sure that his CEO skills were lacking - his managerial skills certainly were, but in terms of code, his output was bad. I mean, really bad. "Coding Horror", hair-on-end bad.
Innocently enough, I began to approach isolated concepts in the code and I hoped to remove their terribleness. I have dealth with student-code, monkey-faking-it-code, and i'm-quitting-tomorrow-code, all bad. So I knew exactly what needed to change in many of these cases.
"Dude. Don't challenge GB on his code." I was told.
"Oh comon - if I fix this, we save like 5 hours a month patching and searching for bugs in the whole pile. It's obsiouvsly worth it."
"Worth isn't in the equation. It's not ROA-based. It's emotional. Don't change GB's code. He loves it and thinks everyone else is wrong."
"Well I bet I can show him how this change will improve things." I said confidently.
So I scheduled a meeting and listened as he whiteboarded up why he needed to write a completely new tool. "Because we found Microsoft's one had a bug." This was perhaps true, but when the tool is quite large, one questions that path. I mean, he half-wrote a large tool to mimic an existing one because of one bug. Okay... but when i researched his described "bug" from the vendor and users (MS has a lot of data on this), I found nothing. He seemingly wrote a new tool to replace a one based *not* on a bug, but in it rejecting his bad design.
A red, swirling light blinked on for a second. Whoop! Whoop! Dive! Dive! I had to get to the bottom of how this guy was thinking.
So another meeting, actually several. He began to expain to me his worldview of programming. The dynamics he was trying to achieve. Not a bad goal, but not really part of the business plan, as I saw it. He was in love with his version of how software could be constructed, and quiet/ignorant of how easy it would be to release solid code "the usual way" way faster. He was planning for years of version changes before the prototype was ready and could run for more than a day.
I began a new project. It was a complimentary application as part of the suite they were shipping. It was to replace an existing application and augment its abilities. The business specs were vague, but the technical demands were explicit. It had to accept constant, large changes to the database schema. Why? Because there was no time to do all the analysis.
Think of that last statement. "No time to do the full analysis" - so we're going to write it to accept whatever the customer asks of us. I began to wonder what business we were in. Ideally, you could be in any business until you asked the customer "what do you want?" "Hmm. Ice cream." Okay, here's some software to make ice cream. Sheesh. So no specs, just a large number of iterative prototypes and endless tweaking. Usually this is fast, but when the CEO is out for the day, and nobody else knows for sure when "good" is "good enough", it slows to a crawl. I had to wait until the analyst hat (a small hat) was worn to get feedback.
Well, I stepped up to the challenge, and created a layer of dyanmic data that mirrored the database, but tried to shield the business logic from bombs of changing requirements. I used commonly-available code that worked throughout many companies already. I invented very little, simply reusing what folks found most productive. I was treated like an idiot.
"Why are you doing this like you are? What is the benefit?" He asked me, angrily.
"This is how modern systems are breaking up the impact of changes. The very changes you expressed were going to happen often. It's the beset practice of the industry"
"You're not listening. The market doesn't know our product. Efficiency is not effectiveness. We have a model in place."
"Your model is full of bugs, and has inherent design flaws. I didn't want to create a product that just got to the level of the current applications, but surpassed them."
"Well, now we have to maintain 2 models, and nobody knows how yours works either."
"Not true, I've used code that is fully documented, has a huge base of folks knowledgeable in it. It's from the internet and is already in working systems, not something I made up in my basement."
After a few heated meetings like this, we silently agreed to not talk to one another. Not very good for an analyst and programmer relationship. Occasionally, I'd get emails challenging my releases or designs. "Thanks for the cheerful attitude" I'd write, CC'ing the audience. I wanted to kill him with kindness. Well, actually, I just wanted the programmer to die, the CEO guy could shake hands and type memos as long as he wanted.
Now, fast forward 1 year. Cancel the "different" project because of "lateness", start the technical salvage of the code into other projects, and then present a *new* design for the such a system. (Actually, just more detail of the original design, since it was still good).
Said design is rejected, so 3 engineering members quit. I get a month to unwind and finally (remember this part?) start contracting around town. Whew! What a crazy place.
It began as an exciting departure from a few years of corporate-job software-guy doldrums. The surroundings were getting less and less exciting, and the folks I was developing with didn't want to excel at their technical expertise; they wanted traffic to go away to/from job and the 3% raise to land on them. Exciting as watching dogs poop.
So I jumped, ready for the consulting world. Except a funny thing happened along the way. I ran into some friends that were in a startup, and wanted to try and make it succeed. They were working in a neat concept and needed more help. The money was right, so I entered as full-time.
Well, one trip through the 400,000+ lines of code (for 40 screens) there gave me food for thought. It was written by someone seemingly out of touch with how client-server software is written for the past 10 years. Custom code for needless tools, buggy designs that poorly mimic things you get out of the box, etc. I took it as a challenge; the gauntlet was thrown! I was going to introduce a world of new modern designs, and turn the codebase into a humming, smaller, porche-engine of strength. Or so I thought.
"Um, who wrote all of this?" I asked. Several conversations starting like this are best condensed as:
"Oh, well GB." [name withheld to protect the crazy]
"GB? THE GB? The GB who is now CEO?"
"Yep."
Now for a company of 17 people this isn't rare. Plenty of software people get a fun idea, write it in their basement for a few years and then try to build a little company around it. However, this person was performing two roles actively: Suited CEO and investment cheerleader, and midnight-frantic programmer guy. I can't say for sure that his CEO skills were lacking - his managerial skills certainly were, but in terms of code, his output was bad. I mean, really bad. "Coding Horror", hair-on-end bad.
Innocently enough, I began to approach isolated concepts in the code and I hoped to remove their terribleness. I have dealth with student-code, monkey-faking-it-code, and i'm-quitting-tomorrow-code, all bad. So I knew exactly what needed to change in many of these cases.
"Dude. Don't challenge GB on his code." I was told.
"Oh comon - if I fix this, we save like 5 hours a month patching and searching for bugs in the whole pile. It's obsiouvsly worth it."
"Worth isn't in the equation. It's not ROA-based. It's emotional. Don't change GB's code. He loves it and thinks everyone else is wrong."
"Well I bet I can show him how this change will improve things." I said confidently.
So I scheduled a meeting and listened as he whiteboarded up why he needed to write a completely new tool. "Because we found Microsoft's one had a bug." This was perhaps true, but when the tool is quite large, one questions that path. I mean, he half-wrote a large tool to mimic an existing one because of one bug. Okay... but when i researched his described "bug" from the vendor and users (MS has a lot of data on this), I found nothing. He seemingly wrote a new tool to replace a one based *not* on a bug, but in it rejecting his bad design.
A red, swirling light blinked on for a second. Whoop! Whoop! Dive! Dive! I had to get to the bottom of how this guy was thinking.
So another meeting, actually several. He began to expain to me his worldview of programming. The dynamics he was trying to achieve. Not a bad goal, but not really part of the business plan, as I saw it. He was in love with his version of how software could be constructed, and quiet/ignorant of how easy it would be to release solid code "the usual way" way faster. He was planning for years of version changes before the prototype was ready and could run for more than a day.
I began a new project. It was a complimentary application as part of the suite they were shipping. It was to replace an existing application and augment its abilities. The business specs were vague, but the technical demands were explicit. It had to accept constant, large changes to the database schema. Why? Because there was no time to do all the analysis.
Think of that last statement. "No time to do the full analysis" - so we're going to write it to accept whatever the customer asks of us. I began to wonder what business we were in. Ideally, you could be in any business until you asked the customer "what do you want?" "Hmm. Ice cream." Okay, here's some software to make ice cream. Sheesh. So no specs, just a large number of iterative prototypes and endless tweaking. Usually this is fast, but when the CEO is out for the day, and nobody else knows for sure when "good" is "good enough", it slows to a crawl. I had to wait until the analyst hat (a small hat) was worn to get feedback.
Well, I stepped up to the challenge, and created a layer of dyanmic data that mirrored the database, but tried to shield the business logic from bombs of changing requirements. I used commonly-available code that worked throughout many companies already. I invented very little, simply reusing what folks found most productive. I was treated like an idiot.
"Why are you doing this like you are? What is the benefit?" He asked me, angrily.
"This is how modern systems are breaking up the impact of changes. The very changes you expressed were going to happen often. It's the beset practice of the industry"
"You're not listening. The market doesn't know our product. Efficiency is not effectiveness. We have a model in place."
"Your model is full of bugs, and has inherent design flaws. I didn't want to create a product that just got to the level of the current applications, but surpassed them."
"Well, now we have to maintain 2 models, and nobody knows how yours works either."
"Not true, I've used code that is fully documented, has a huge base of folks knowledgeable in it. It's from the internet and is already in working systems, not something I made up in my basement."
After a few heated meetings like this, we silently agreed to not talk to one another. Not very good for an analyst and programmer relationship. Occasionally, I'd get emails challenging my releases or designs. "Thanks for the cheerful attitude" I'd write, CC'ing the audience. I wanted to kill him with kindness. Well, actually, I just wanted the programmer to die, the CEO guy could shake hands and type memos as long as he wanted.
Now, fast forward 1 year. Cancel the "different" project because of "lateness", start the technical salvage of the code into other projects, and then present a *new* design for the such a system. (Actually, just more detail of the original design, since it was still good).
Said design is rejected, so 3 engineering members quit. I get a month to unwind and finally (remember this part?) start contracting around town. Whew! What a crazy place.
Subscribe to:
Posts (Atom)