Analogy Mismatch

Posted by Phillip Jackson on 28 December 2009

I was sent this this morning:
http://zedshaw.com/essays/master_and_expert.html

It’s been chewing at me all day. I don’t know that I agree with this.

I think the analogy is wrong in part. In the analogy, the master is in control of what he knows and practices. But I still say that he needs to check his form as he practices to make sure bad form doesn’t become habit. This is analogous to ‘unit-testing’ himself, not the extraneous movement during performance of a young learner. His code, will always and forever be his own. He need not protect himself from other’s modifications of his form, only his own degradation. But even here unit testing is required.

Comparing the young learners unit test writing to the final performance is not a valid pairing. Unit tests are written when practicing and rehearsing. (Note: practicing is writing code at home, and rehearsing is writing code at work) The final performance, the operation of the code in production, doesn’t involve unit tests. The creation of code involves unit tests. You can’t compare the creation of unit tests during the writing of code to the extraneous operations in a young learner’s final performance. Those aren’t the same thing.

I fear his point is muddled in his own head. The practice of a martial art is analogous to the programmer writing code. The performance of the martial-art in competition (the result of practice, refinement and quality checking) is analogous to the performance of the code in production (the result of writing code, refactoring and unit testing).

He is comparing unequal things, and therefore invalidates his argument. His point is, I assume, that a master accomplishes a task (victory in combat, or automation of a business task) with the least effort possible, but the details are mismatched.

In software we make analogies for –everything-. Most times because we have to. People we are explaining things to won’t understand the context of the deeply technical or specialized things we are describing so we create an analogy to something they do have context in. But we need to be careful that our analogies are valid and we are comparing two equal things.

No Comments

Comments Violate DRY

Posted by Phillip Jackson in , , on 19 November 2009

Was talking to a colleague, friend and mentor Troy Bourgeois and in the course of the conversation he said something that struck me. He said writing code comments is just another form of repeating yourself.

I’ve been thinking about this all night. Just like copied code is a symptom of not getting the abstraction right, commenting is a symptom of not getting the code right. Code is supposed to communicate its intent. If it doesn't, then you comment in order to do so.

The real question here is why I feel like I have to add a disclaimer every time I say commenting is a smell? Whether it’s in front of college students, professionals or colleagues. I truly believe that the desire to write a comment is a sign that your code doesn’t communicate effectively, but I guess I fear that people will not strive to write code that doesn’t need comments and rather just omit them.

As Uncle Bob said:
It's not about _omitting_ comments, it's about making them unnecessary.

1 Comment

No one is trained to do it

Posted by Phillip Jackson in , , , , on 15 November 2009

In reference to:

The key here is that we are all at a loss in this field. As far as professional software development goes, no one is trained to do it via our education... not even the CS people, so we need to be constantly searching for professional practices that have been proven in the field to work and evaluate them for inclusion in our own work.

Now that doesn't mean once you've found something that works you are done and can coast until retirement. This industry is still quite young and as professionals in it, during these formative times, we must keep our ear to the ground and our eyes to the horizon because even the professional practices that work fine for *us* at the *moment* may not be the best possible as new methods and techniques are tried and evaluated every day across the globe.

We are professionals in an exciting field at an exciting, and notably unregulated, time. With that comes a lot of freedom and therefore a lot of responsibility that we must impose upon ourselves. Even now, clients can't tell the difference between good development and bad development until it is way too late so we cannot wait for the market to drive us to find better techniques, because it can't. *We* must drive ourselves. But in much the same way we have difficulty differentiating between high skilled and low skilled developers until the product falls, crashing down around us. And, truly, even then we have difficulty determining the fault because of the overwhelming number of variables involved in the project. Iterative methodologies are our *current* attempt to overcome this problem by pushing awareness that before only came at the end, up to the beginning. Giving us the chance to evaluate, adjust, correct and improve.

We must be constantly practicing and training ourselves in new methodologies for "the pursuit of unattainable perfection". 100 years from now, software developers will only be able to dream of the freedom-to-achieve that we have today in this field. Much like we view the wild west, I’d imagine.

We have a chance today to be really great and we must put forth the effort to reach and take it ourselves. For when the day comes that client’s can tell the difference between good and bad development, you do not want to be caught napping.

No Comments

McConnell: Software Engineering, Not Computer Science

Posted by Phillip Jackson in , , , ,

Chapter 4: Software Engineering, Not Computer Science
“A scientist builds in order to learn; an engineer learns in order to build.”
— Fred Brooks



The chapter linked above challenged some beliefs that I hold to very tightly, but it also brought clarity and confirmation to notions that I’ve deduced myself and held for a long time. It’s a long article, but worth it. I won’t soon forget the House/Shed Comparison I expect.

As with everything I’ve read from McConnell his terminology can be vague and, therefore interpreted in vastly different ways by different people. For me, in the House/Shed Comparison, I consider McConnell to be referring to ‘Engineering’ as application design, not construction. So if one were to say: “Look‘a here buddy, I’m just constructing a shed, therefore I don’t need to implement SOLID principles, write patterned code, or create unit tests…” I will call BS. Because it’s not in the integrity of construction he is saying an insulated shed is over-engineered, but rather in its bloated feature set. Both the house and the shed need a solid foundation, square frames, and twice-measured lengths i.e. quality construction. It’s in the unnecessary amenity of insulation for the shed that McConnell finds over-engineering.

For those who think McConnell’s reference to “code-and-fix” means iterative development, I direct you to this definition: http://en.wikipedia.org/wiki/Code_and_fix.

But alas, to the point… ;)
Regardless of my interpretation, I’m curious to know yours.




Excerpts (for the ‘TLDR’-ers):
[…]
Engineering vs. Science
With only about 40 percent of software developers holding computer science degrees and practically none holding degrees in software engineering, we shouldn’t be surprised to find people confused about the difference between software engineering and computer science. […] Scientists learn what is true, how to test hypotheses, and how to extend knowledge in their field. Engineers learn what is true, what is useful, and how to apply well-understood knowledge to solve practical problems. Scientists must keep up to date with the latest research. Engineers must be familiar with knowledge that has already proven to be reliable and effective. […] An undergraduate science education prepares students to continue their studies. An undergraduate engineering education prepares students to enter the workforce immediately after completing their studies.
[…]
This puts computer science students into a technological no-man’s land. They are called scientists, but they are performing job functions that are traditionally performed by engineers, without the benefit of engineering training. The effect is roughly the same as it would be if you assigned a physics Ph.D. to design electrical equipment for commercial sale. […] We would expect the equipment designed by the physics Ph.D. to work, but perhaps to lack some of the robustness that would make it usable or safe outside a laboratory.
[…]
[workers educated as computer scientists] focus narrowly and deeply on minor considerations to the exclusion of other factors that are more important. They might spend two days hand-tuning a sorting algorithm instead of two hours using a code library or copying a suitable algorithm from a book.
[…]
The lack of professional development isn’t solely the software developer’s failure. The software world has become a victim of its own success. The software job market has been growing faster than the educational infrastructure needed to support it, and so more than half the people holding software development jobs have been educated in subjects other than software.
[…]
When a building is designed, the construction materials must suit the building’s purpose. I can build a large equipment shed to store farming vehicles from thin, uninsulated sheet metal. I wouldn’t build a house the same way. But even though the house is sturdier and warmer, we wouldn’t refer to the shed as being inferior to the house in any way. The shed has been designed appropriately for its intended purpose. If it had been built the same way as a house, we might even criticize it for being “over-engineered”—a judgment that the designers wasted resources in building it and that it actually isn’t well engineered.
[…]
Today’s pervasive reliance on code-and-fix development—and the cost and schedule overruns that go with it—is not the result of a software engineering calculation, but of too little education and training in software engineering practices.

No Comments

Duct Tape Developers? I'm done with this guy

Posted by Phillip Jackson in , , , on 23 October 2009

“…but it seems to me like a lot of the Object Oriented Design principles you're hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture's sake. It doesn't seem like you could actually get any code written if you're spending all your time writing 8,000,000 unit tests, and every single dinky little class that you need to split a URL into four parts becomes an engineering project worthy of making a bridge, where you spend six months defining 1000 little interfaces. They've just gone off the deep end, and I don't think these people write very much code if they're coming up with these principles, to be honest, it doesn't even make sense.”

“One of the SOLID principles, and I'm totally butchering this, but…”
Yes Joel you are, let’s just stop there before I put that butcher knife to better use.

Joel has given up on what Brian Rigsby calls ‘the pursuit of unattainable perfection.’ If you aren’t pursuing perfection then, at *best*, you are sliding down into mediocrity. And honestly I think he gave up when he was Program Manager for the Excel team and his VBA garbage.

I think it’s safe to say this man’s creek is getting foggier by the day. As someone that has packed his own parachute before I would like to think he has an appreciation for a job done well. I mean we all assume EMTs know what they are doing… right:

Yes that duct tape went on faster than a gauze dressing, and I’m sure it’s getting the job done, though I can’t figure out what that job is without asking the person that put it on. More importantly I pity the guy that has to make a change to it. Our clients are assuming that we are also doing it right, and to not do it right, regardless of your excuse, is to invalidate that trust. If writing software well takes too long, then keep practicing until it doesn't.

Jon you are right, no doubt there is probably something good this clown has done or said in the past… but I don’t eat shit hoping there is a berry in it. ;)

No Comments

Interaction Design

Posted by Phillip Jackson on 18 February 2009

“Developing the user interface of a professional software application is not easy. It can be a murky blend of data, interaction design, visual design, connectivity, multithreading, security, internationalization, validation, unit testing, and a touch of voodoo. Considering that a user interface exposes the underlying system and must satisfy the unpredictable stylistic requirements of its users, it can be the most volatile area of many applications.”
Great term. I’m asked to do a little Visual Design magic at the end of the design phase and again at the end of the development phase to make sure the application is ‘slick’ enough to blind the client in a demo. But Interaction Design is where the gold’s at. It’s our best chance to get the user to experience pleasure when using the application, make them fans, or at least give transparency, allowing the user to focus wholly on the job they are doing, not the software obstacle they are clicking on all day. It is something we need to be doing to ensure the very expensive application the client is buying will fulfill their needs. But this company never does it. Why? Because we like to gamble? Because we like to fail? Because we don’t know any better? Or maybe because we don’t ask the right questions of the right people at the right times?

Is it as simple as requesting a future-user of the application be involved from the beginning and stay involved for usage evaluations and design refinements each iteration? Only one way to find out.

If you ask the client for an investment of an actual user to assist, and you and your PM get thrown out of the meeting and lose the contract, I’ll buy you lunch to cheer you up. ;)

No Comments

Divergence

Posted by Phillip Jackson on 03 January 2009

March 06, 2007 Phillip Atkinson sent this link:
http://www.joelonsoftware.com/articles/APIWar.html

From the article:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

Wow.

As for the rest. I’m all about delivering products to the user as fast as possible. Period. Even in managed langs it’s not fast enough for me. My dream is to envision a UI and then once the UI is constructed be able to wire up the functionality to it without effort. I’m a visually oriented guy and am not as concerned with how cool it would be to create my own X, Y, Z objects to handle A-F data as I am concerned with how cool it is to provide tools to the client(often myself) that can make their life better in a near immediate timeframe.

If the world’s core development population views managed languages like I view VB6, then I’m going to have to just suck it up. While they are flexing their muscle writing that app in C, C++ I will have whipped out several and learned a significant amount about the interface between Developers and Users while the C guys learned a little about the interface between Computers and Developers but not much more than they already knew. I see the world changing and it will very soon be accelerating even more. Once that last person, that didn’t grow up around computers, retires then the demand for software that does everything needed and does it right now will grow even stronger than it already is.

For years I’ve balked at business application developers calling themselves Software Engineers. I’ve done so because as this industry matures there will be a divergence in what is now a single group of professionals. I see Software Engineers emerging as those that are focused solely on writing software, but on the software that exists close to the metal with knowledge of: compilers, linkers, machine lang, memory management, binary arithmetic, semaphores, dining philosophers, red-black trees, Turing machines, non-deterministic finite state machines, framework creation. The diverging vector are the Software Developers (or Application Developers) who are focused on delivering functionality to the masses. Yeah yeah, it’s a computer… so what… watch what I can make it do FOR YOU. They exist in an area removed from the metal; in frameworks and with tools that facilitate rapid construction and solid functionality. They are about fulfilling the user’s needs and transforming a computer into a useful device. The ultimate device.

Currently there are those that can live in both realms. They fully understand compiling, linking, NAND gates and voltages and write assembly code regularly while also being able to construct a J2EE app with EJB, and do it well. There are not many. The university view is teach them to be Software Engineers and they can become Software Developers if they so choose because the learning curve on becoming a Software Developer is flattened by the ease of use of the quality of tools and frameworks that facilitate rapid development. I can’t argue with that now, how else are we going to create Software Engineers? But who will take on the responsibility of training Software Developers? The employers? How is that working for you?

I’d like to declare that I’m proud to be a Software Developer. But there is a part of me that looks down my nose that those developers that don’t know the fundamental Computer Science stuff. As if that makes me more of a man. I learned C at LSU, C++ at SELU and have coded a fair amount in them. Do I miss it? Not even a little bit. No one misses STDLIB, do they? And for me they are in direct opposition to my dream of rapid development.

I’d characterize this stage of the software industry as the Wild West. It’s after the pioneers have settled, but before cities have emerged. Though with my employer choice I was careful not to be the Town Mayor shaking his fist as the cowboys ride through town, I’m also not the cowboy that does whatever they please because they can. I’d like to think of myself in between. No home to speak of, but has a strong sense of what is best for the current town, country and most importantly the people involved, with the will to enforce that belief.

DOS to Windows was like the pioneer’s log cabins and mud huts to wood plank construction. The new shift from Windows XP and WinForms to Vista and WPF is less dramatic on the outside, but is a required part of the inevitable future growth. As the divergence becomes greater, things like the Vista Bridge will be standard fair as insulation from the realm of the Software Engineer will become an accepted reality.

Back to the point. So MS is dumping backwards compatibility in favor of a shift forward? So what. Since when is it new that we have to learn something new. Take something far enough and it will stagnate, other industries would stay stable instead. Do we crave chaos? Maybe so, or maybe it’s because of the phase of growth our industry is in. This shifting foundation is the world we live in, we are Software Developers, we are beholden to the Software Engineers on the small scale. In the grand scheme though, Software Engineers are reacting to the needs we express.

No Comments