Ease-of-Use SDKs Are Just Toys

Was reading up on mobile development now that the Samsung Galaxy Tab is poised to compete with the iPad and the trend of mobile business application development is gaining steam and breadth at the world's largest companies to give visibility into the company to executives on the move as well as technical information to onsite supervisors.

This article struck me as a sobering voice opposing this regression back to the dark ages of MS Access style hobbyist development.

By Richard Adhikari

For the TL;DR's here is the important bit:
Ease-of-Use SDKs Are Just Toys

It's almost axiomatic in the high-tech industry that SMBs lack the expertise and in-house tech staff to do much in the way of IT work, so app development isn't easy for them. However, Apple and Google have unveiled SDKs are claimed to simplify the process.

For instance, Google's App Inventor claims to make the task on Android easier.However, it doesn't do away with the need for programming skills.

"Fundamentally, App Inventor doesn't appear to be that much different from Visual Basic," Randy Abrams, director of technical education at ESET, told TechNewsWorld. "I consider Visual Basic programming with Tinker Toys." App Inventor is "a way to get non-programmers interested in development," Abrams said.

When such non-programmers run into the limitations that drag-and-drop programming entails, some may be inspired to learn more and become more savvy. In other words, unless the programmer is sufficiently skilled, apps created with simplified SDKs may not be robust enough to meet SMBs' business requirements. And if the programmers are that skilled, SMBs may not be able to afford them.

I find a great deal of truth in the above statement. The industry doesn't need tools so easy to use that Aaron the Professional Accountant can write business applications for his needs; the industry doesn't need tools so easy to use that Adam the Amateur Coder can try to figure out how to glue some things together that might work; we need tools so easy to use that Dave the Professional Developer can write quality business applications for Aaron more quickly.

People or Projects?

I used to be Projects over People. The work was all that mattered. Woe to those who came between me and delivering the highest value to the user via the cleverest user interface and highest quality of code I knew how to produce. Reminds me of a Robert E. Howard quote, but we will get to that in a bit.
Why? Considering the amount of time I’ve thought about it, you would think I would have a better answer. But alas all I have are these: The illusion of a meritocracy maybe? A meritocracy that, because of it’s existence in our schooling, I thought existed everywhere. If I wrote the best software, everyone would (somehow) know and I would be respected. I know you just chuckled. I didn’t hear it, but I still know you did. That’s ok, it was naive of me and warrants a good laugh.
Maybe it was a solution to a flaw I saw in using clients to measure project success: it’s not very scientific. The phrase “It’s not what you know but who you know” applies here and reeks of corruption that I despise. Which brings up another Howard quote:

“Civilized men are more discourteous than savages because they know they can be impolite without having their skulls split, as a general thing.”
               –Robert E. Howard (The Tower of the Elephant)
I saw clients evaluating the success of a project as a fail because at the time I thought it mattered that they understand the internal workings, you know, all the crap I had to go through and all the ‘brilliance’ I showed on the inside of the app. They can’t understand it, and it doesn’t matter if they do. I also didn’t see them as capable of giving honest feedback because of the naturally adversarial relationship that occurs between one paying for work and one delivering the work. But the relationship between these two need not be adversarial.
Maybe the true reason: it is in my nature, it’s in your nature, it’s in our nature to strive to be the best and people are competition, or just get in the way. I need a machine, an IDE and a compiler to make users lives better. Go away and let me get to saving the world. ;)
This Projects-over-People philosophy almost cost me one of the most valued relationships I have now. It was my manager at the time that made me realize Projects will come and go, but the relationships you make with the People you meet may last a lifetime. He is a gentle man and his gentleness is something I appreciated while working with him and began to emulate. So after the longest and most challenging project I’ve ever had in my short career, one that I alone followed to it’s full end, sacrificing everything else in my life, protecting it and defending it, I flipped. I became People over Projects. On my next project I nurtured the relationships with the client-users, managers and developers first and foremost, to the detriment of the codebase.
That was some time ago and the codebase that resulted has still not shipped. For my sake, the sake of the people that would have to use it, and the sake of the developers that would have to maintain it, I hope it never does. My change in philosophy was not the entire reason the project failed nor was it the determining factor, but I would be lying to myself to say it didn’t contribute.
What I see now is that one or the other is an insufficient solution. If you deliver a great app but all you made were enemies, you have failed because very quickly you will find there is no one that wants to work with you or wants you working for them. If you make a bunch of new friends but didn’t enforce coding practices you know are necessary to ensure the quality of the application and therefore develop a non-maintainable application, you have also failed because you didn’t do your job which was to deliver a functional application that can afford change. Both are needed.
A successful career is built by delivering a great application to the users, while leading your team, not by instruction or condescension but by example.  Prove to the team why the methodologies you use are worth the extra work. If you can’t prove that your methodologies are worth it, then you need to reconsider your chosen methodologies or practice to increase your skill in using them. This builds trust between you and the developers you work with in a positive way. An adversarial relationship with the client can be avoided with an agile project approach that delivers an application in pieces that is a good fit for the user as the target moves into focus. The client gets a front row seat to the addition and modification of functionality and trust and confidence is built as they watch you encounter and overcome obstacles along the way (especially the obstacles the client creates themselves as they refine the design).
Being Projects over People ignores the fact that no large software system can be built by one person in a short amount of time, which is not practical. Being People over Projects requires one to tame their individual desires of conquest for the perceived betterment of the individual egos in the group, which is not natural and benefits no one. 
“Let me live deep while I live; let me know the rich juices of red meat and stinging wine my palate, the hot embrace of arms, the mad exultation of battle when the blue blades flame and crimson, and I am content.

Let teachers and philosophers brood over questions of reality and illusion. I know this: if life is illusion, then I am no less an illusion, and being thus, the illusion is real to me. I live, I burn with life, I love, I slay, and am content.”
               –Robert E. Howard (Queen of the Black Coast)
The above quote, I thought, supported my initial Projects-over-People philosophy but I’ve found in practice that living your professional life to the fullest cannot be sustained without a balance of conquest and cooperation. The quote “It’s not what you know but who you know” is emphasizing the reality that without people, one cannot become successful. For the first part you must be great at what you do. But being only this will leave you alone to appreciate yourself. For the second part you must include, cooperate, and treat kindly the people you work and with and for. But being only this will provide you with the illusion of success that will soon evaporate once it is seen that you are not as good at your job as the illusion has led people to believe. Done together you practice and hone your craft to deliver the greatest applications you can while cultivating relationships with people that will spread your software’s success, and appreciation for your skill as well what a pleasure that it was to work with you.
Be good at what you do, and be good to the people around you so that you may have more opportunities to be successful.

Analogy Mismatch

I was sent this this morning:

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.

Comments Violate DRY

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.

No one is trained to do it

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.

McConnell: Software Engineering, Not Computer Science

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.

Duct Tape Developers? I'm done with this guy

“…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. ;)