Rampant CodeCraft

Ease-of-Use SDKs Are Just Toys

2010-09-22T15:01:00.003-05:00

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.

TechNewsWorld: The Good, Bad and Ugly of Custom-Built Mobile Apps

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?

2010-03-03T23:07:00.001-06:00

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 lead 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

2009-12-28T19:28:00.001-06:00

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.

Comments Violate DRY

2009-11-19T23:09:00.009-06:00

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

2009-11-15T11:10:00.009-06:00

In reference to:

McConnell: Software Engineering, Not Computer Science

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

2009-11-15T01:57:00.009-06:00

Chapter 4: Software Engineering, Not Computer Science

“A scientist builds in order to learn; an engineer learns in order to build.”

— Fred Brooks

http://www.stevemcconnell.com/psd/04-senotcs.htm

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

2009-10-23T22:34:00.013-05:00

http://www.joelonsoftware.com/items/2009/01/31.html

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

Interaction Design

2009-02-18T01:50:00.000-06:00

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

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

Divergence

2009-01-03T17:01:00.000-06:00

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.

Wagging the Dog

2008-12-11T18:10:00.001-06:00

The focus of the design iteration is the document. The product of the design iteration is this document. The software is defined by this document. The estimation is created from this document. The sale is secured with this document. Client trust is established by this document. Test cases are made from this document. Who we are as a company is represented by this document.

All wrong.

The focus of the design iteration is the design. The product of the design iteration is the design. The software is defined by this design. The estimation is created from this design. The sale is secured with this design. Client trust is established by this design. Test cases are made from this design. Who we are as a company is represented by this design.

How do we communicate this design to the client? What does the client need? Let's see, the client needs to be able consume this design in its entirety and, if complex, the order in which components of the design are conveyed may need to be structured so as to build ontop of each other to communicate a larger concept, implementation or idea. A document sounds like a good candidate for this. It can be read from beginning to end so consumption of the entirety is straight forward. The order of consumption can be predicted and so the order of component description can be arranged as desired. The document is not the design. It is a representation of the design; an expression of the design selected for it's suitability to the intended audience.

How do we communicate this design to the development team? A document? Turns out that's not working out so well. In this case a document is not really the most suitable form for the audience. We have found in the past that if the design's primary medium is a document it is difficult to maintain, to modify, to update, to change, to track changes, to work on concurrently etc.

So we need to be able to express the design in document form for the client. But this form isn't suitable for the development staff. We need a primary medium for this design to exist that it gives the management, development and QA staff what they need while also being exportable to a document for the client.

We are going to try a Wiki. This should give the development, QA, and management staff the flexible, easily editable format they need while we can programmatically flatten the Wiki into a specification document for the client. Hopefully later we can get out of this upfront design and design things in the wiki right before we need to develop it. Our first step to getting there is to move from a big upfront design (BUFD) to a medium upfront design. The document format is only required for upfront designs. If the client is working with us hand in hand, then they don't ever have to read the design from end to end, they only need to focus on a single feature implementation: one wiki page.

Some advantages of the wiki are:

When defining the design, the developers aren't in a document, they aren't evaluating the size of the document, they aren't comparing document sections before or after it for page length or content. Their sense of done is soley based on the detail they have inscribed within the wiki page they are focused on.
Wiki pages, images and other resources are versioned, and are versioned better than tracking changes in a document provides.
There is no sense of beginning and end in the wiki. Wiki pages that are related to the page the developer is currently either designing, or constructing software from, is linked to from that page. This puts all the information the developer needs within easy reach.
During development the development, QA and management staff are focused on portions of the document and not the entirety, when the client reads the design in document format they will be able to consume the entirety from beginning to end because the document version provides this.
Wikis are easy for multiple people to edit at the same time. no passing around a document or merging document sections together.
In digital format they are very easy to navigate.
In document format the embeded links to other document sections is inherent and doesn't require one manually entering in the links.

TFS wants to be the source for the design, but the UI is really difficult to interact with, and the navigation is worse. It is not ready to be used this way yet, so we will use the wiki until TFS is ready.

Event: Requirements Documentation

2008-12-04T01:21:00.000-06:00

My company produces software that doesn't break. Our entire reputation is based on that. But behind that software is code that even the original authors have real trouble modifying. Why is that? All software produced everywhere is assigned a version number. Wikipedia has 4000 words on the subject of Software Versioning. Versioning is inherent to software. We know that software will be updated, modified, changed. So this begs the question: If we know that software will need to be modified, then why have we been setting ourselves up to fail by not writing code that can be modified? We've relied on something characteristic of software production for small business: there is no version 2. Problem now is, this is no longer our niche in the market. We have grown and produce software for large corporations now.

We are in the early stages of an event here. Parts of this are changes in the fundamental way my company authors code. Gone are the days of "Git-er-Done however you need cuz the client can't afford a version 2". Now is the time of "Why did this maintenance modification cost more than the original construction?". I could go on, but I mention this only to frame a point. Our move to code creation that is able to afford change is not this singularly great idea for a problem that exists in the development phase. The new concepts and skills can be applied to everything we do here.

In the development phase we produce what the client requests: software that gets a job done and doesn't break. For the past however long, that is all that was required. Our search for efficiency, combined with a track record of software not needing an update because it doesn't break and clients not requesting a second version has resulted in us gaining efficiency by cutting out all real considerations for future extension or modification. Our ability to do this well has resulted in larger clients with larger needs. And now when their large software solutions need an update; when version 2 is requested, we find ourselves in real trouble. This situation not only exists in our development phases of projects. It also exists in the requirements and specification phases.

In the design phase we produce what the client requests: a document that defines the intent, appearance and functionality of the software to be produced. But after development based on that document is over; when the client requests a version 2 and we need to refer back to the document to understand version 1, we find ourselves in real trouble. Why? Because we don't document the changes made to the product during development. We can't keep up, and we have never had a real need to, so we don't. Our specification documents have just enough detail to satisfy the client. The document leaves so much of the technical detail up to the developer coding, that within a matter of weeks what is delivered to QA has diverged from the specification so far that the document is useless and the QA assigned needs the new specification communicated to them directly from the developer before they can begin testing.

What is needed is method of documenting requirements that can be so easily modified that the developers actually do update the documentation as the application is refined, or requirements change or the application design diverges from the original for any reason.

They're Doing it Wrong

2008-11-08T15:52:00.000-06:00

Cowboys – Not team players, they are either very well versed in the current framework or not versed in the framework at all. If on a team they implement solutions without consideration for the other team mates. If solo, they develop with little consideration to future maintenance developers or change. They are great in meetings, they shoot from the hip, are often wrong, generally instill immediate confidence, but when they ride off into the sunset they leave everyone feeling hollow. They often generate more problems than they resolve, but the problems they create generally aren’t directly relatable and are blamed on the existing code base, or other peoples work.

Firefighters – Are called in when a project spins into a runaway or fires rage out of control in Production. They are highly skilled, very driven and goal oriented. They are there to fix a problem and do so in short order. They don't answer to you they answer to the stakeholder or your boss's boss's boss, and therefore they often care little about the resulting code. Much like a real firefighter will destroy your house with the fire hose to put out the fire in the kitchen. But hey, it’s not on fire anymore, right.

Pitbulls – Can range from non-technical to very technical. The determining criterion is their incessant need to be an ass. They almost never admit when they are wrong, especially in the face of overwhelming evidence. They are agitators used to force a stakeholder’s desires on the project. They are passive aggressive and Roosters. If a pitbull is the product owner the project will fail. The only way to handle a pit is to not step in the ring, but rather deal directly with the stakeholder holding the leash. They are unhappy about something or feel powerless, that is why they aquired a pitbull. Resolve that problem and the pitbull problem will resolve itself.

Architects – Talk a lot. No really A LOT. The rule is if you can get an architect to stop talking, then they aren’t really an architect. Be wary of the ones with charisma and technical skill. They are very dangerous. Where architects tread, ivory grows: this is their job. Regardless of any other consideration get to know your architect. You can learn a lot from just sitting and listening, just don't make them 100% of your information base. It is when an Architect stops practicing the craft of code writing that they become dangerous.

Skillz

2008-11-08T15:02:00.000-06:00

Ability to QA a system
This facilitates the developer being able to catch and resolve issues before they become problems.

Write Effective Unit Tests
There is nothing I know of that enforces good Object Oriented design more potently than Unit Tests. It's not about a specific unit testing program because being able to create unit tests is a fundamental skill. It is a skill that translates across all programs and methodologies. Creating good unit tests is a science, and like any science can be perfected with enough experience and practice. The first thing people find when starting to write unit tests for the first time is that their code is not unit testable. They thought they were object oriented design masters and find that they’re doing it wrong. Unit tests flush out this misconception and force good object oriented design. Raw experience writing unit tests is required before quality code coverage is achieved. I would like to see students write unit tests in the major software project courses and give them this experience, as well as force the code into good OO design.

For more information:
http://en.wikipedia.org/wiki/Unit_test
http://en.wikipedia.org/wiki/Test-driven_development (TDD)

Refactoring
If you work your entire career creating new software for clients that don’t change requirements then you are the one, because no one else gets to. You will have to maintain a code base or adopt a code base or have to modify a code base. Refactoring skill is required; otherwise you’re just fumbling around hoping your changes work out, relying solely on your QA department to catch problems before the client does.
Refactoring is key to the new agile implementations, but again, more importantly the ability to transform existing code into unit testable, object oriented, patterned code is key to a successful career as well as being a chief tenant of any agile implementation. Being able to architect a great pattern-rich, mature solution and code it from the ground up is great. It’s still not simple to do, but when done right is a beautiful thing. More likely than not though you aren’t given that opportunity. You are given an existing code base and are asked to make changes. This can be in the form of a rotten code base written years ago, to an existing code base that is part of an active scrum sprint whose requirements were changed at the end of the last sprint. Either way being a code alchemist, being able to transform existing good or rotten code into the appropriate code is a huge skill. It’s also a fundamental skill that permeates through languages, frameworks and platforms. If this skill was focused on you would see the code that people adopt improve in quality, not just being retro fit in any way possible for the immediate need.

For more information:
Refactoring, Martin Fower, 1999.

Design Patterns
So many fields have achieved greatness today because they build upon the lessons learned in the past. For the vast majority of the Computer Science and software development field we restart from scratch every time. There is little growth. We have many of the same problems today that people in the 70s and 80s had. Design patterns facilitate mature initial design and simple/reliable extendibility later among so many other things. This is a key part to all the new agile implementations, but more importantly this is key to growth of the field, and growth in the field. For those looking for shoulders to stand on, here they are. These patterns reflect over 30 years of design refinement and extension. Software developers are foolish not to implement them. That is assuming they know Design Patterns for software development exist. That’s one of the problems, many are not aware of design patterns. Identifying patterns in use in code they are to maintain, identifying when to apply patterns to a new design, and identifying which pattern to refactor to are all difficult skills to master.

For more information:
Head First Design Patterns, Freeman, Sierra, Bates, 2004.
http://www.dofactory.com/Patterns/Patterns.aspx

Performance Testing
If there is a bottle neck, it has to be found before it can be fixed. There is a skill involved in finding the problem and a whole different skill set involved in improving performance.

Something's Wrong

2008-08-23T23:03:00.000-05:00

I dropped this nugget in a comment on the blog of my company's owner. One of the last lines in the comment was bait, but no one took it (or maybe no one read it). So I've decided to post it in a place that is guaranteed no one will read it ;)

The Post:

There is something fundamentally wrong to me about the size of the failure-potential software development has always had and still carries. Maybe I'm crazy but in other professions is this also the case?

We don't follow engineering principles because we claim that they are too rigid and don't take advantage of all of the flexibility the software universe gives us, but if software's failure rate is as high as I think it is then what does the flexibility really give us? Do we need the flexibility simply because we never get it right?

I say 'we' in the all-encompassing profession-of-software-development sense. Because, well, you know 'we' NEVAR fail... ;)

The point here is that no one gets it right (except in the case of the occasional occurrence of luck or a very flexible and accepting [read: push over] client). Upon neither of these things am I willing to build a career on.

Can all we really hope for is to get lucky project after project, just long enough to get promoted into another role? Do we have to pull out the smoke and mirrors when we don't get lucky on the design in order to fool our bosses and the client into thinking the project was a success? When I switched from mechanical engineering to computer science I wasn't thinking I was going to find the moral clarity of a Peace Corp volunteer, but I also didn't think I would have to cheat and steal to be successful. When we aren’t honest about our work and we make it seem that the troubles we had didn’t exist or were instantly overcome, then we set unrealistic expectations for ourselves, our colleagues and our company.

What is the fundamental problem here (other than the resulting failure)? What is the one desire that supersedes all when an application is done? I feel it every time I release an application: "I wish I could just redesign it", either in part or in whole.

Why do I feel this way? Is it because I screwed up the implementation so bad that I want to go back and fix it? No (well maybe once or twice :). It is because only now, at the end do I understand the business of the client, their needs and the true intent of the software and what functionality the application was supposed to provide. To those who, when done with the application, don’t care when they make the job of 900 users more painful, but rather only care that their bosses and the client business owner buy the illusion that the project was a raving success: I say good luck on somebody else’s team. Because if you are not measuring your application’s success by the positive value you provided to your client’s employees and profit, then you are using the wrong metrics.

Ok so let’s think about this. Why is it that we only know this at the end? Isn't that supposed to be acquired during Requirements gathering / Spec writing etc.? A true understanding only comes from the journey one takes with the client during construction and the feedback given during UAT. You never know if you are right/wrong/close or don't have a clue until you understand thoroughly your operating environment or until the client tells you.

So maybe here is where you fault the developers for not doing their due diligence in extracting this knowledge from the client beforehand. But you'd be, in most cases, wrong. This is because it’s not until the end, after they have taken the journey with you and see the results, that the client has any real understanding either.

Whoa, wait. Doesn’t this fall to the Project Manager/ Tech Lead to set client expectation and ensure that the project’s direction and design provides the client with the software they need?
Yes.

And do the managers/leads do this and correct during development as needed?
Most do.

So what is the problem?
The problem is that the projects in which this occurs invariably run over budget.

So what? The client had to pay more but they are getting the system they need, the system that solves their problem (even though they might not know it yet).
Many people agree with this. In fact, projects going over budget is such a common occurrence that claiming you are going to hit budget is most often perceived as a joke or arrogant. When a project does hit budget and deliver on time that team is immortalized. (See where the motivation to make every project appear to be a success comes from?) While being bedazzled by the efficient delivery, what the client fails to see at the time is that the application is rarely the tool the users need or were promised. Eventually, when the client business owner realizes this… well good luck to you.

Providing the client with the system they need, doesn’t nullify the fact that you told them the system would cost $700K and are now asking them to pay $900K. Ever tried to explain that to the client? Explain that the original design was not going to provide them with the system they needed and that all the time spent in the beginning doing the end to end design and spec writing that you had to assure them wasn’t a waste of money… actually was. Now, not only are they not going to pay the $900K but they also don’t want to pay the $700K either.

So if we only know what they needed once we finish, then how can we possibly build an application that will satisfy their needs the first go round?

More to follow...

UI Design Review

2008-07-30T03:49:00.002-05:00

Slashdot: Software, Tools, Or Techniques For UI Review?

Didn't think I'd see something like this on /. but it is something that we struggle with. Not just good UI design, but somehow bringing UI design, review and refinement into the processes we have.

The company I work for is like a swiss watch company. We are not focused on how the watch looks, only with how accurate the time will be.

Now when you shell out the $200 000 for our watch, you will need to be familiar with the user manual and maybe go to a class or two before you can read the time on the watch, but after 25 years that watch will still have the right time. Seems an extreme example, but in our market the norm is 'unusable' software. Off the shelf focuses on usability because that resells software. We sell service. Our app is sold before the client realizes that the thing will be brutally difficult to operate. We make no investment in resale because custom apps are one-offs, they often CAN'T be resold.

If we provide quality that is an 80/20 mix of kept/sacrificed then the entire 20% of sacrificed quality is in UI design. The outside interface is a reflection of the inside mechanics and that is the extent to which usage is calculated.

For me its knowing what looks good first, then reduction to elegance for usability. I can look at a screen or comp and see that things are out of balance. I recognize when the first thing I'm drawn to in the app is not the most important thing, or is not the beginning of the visual instruction. When the user must extract usage flow paths and usage rules out of the mess of fields on the screen. I don't always know how to fix it, but I can see the problem. Are all my designs best of breed? No, I sometimes get lost in the weeds.

I've studied UI design because I knew its a critical part of selling software as well as software acceptance and general user satisfaction, but found all the education to maybe assist in correcting abstract problems found, but not how to spot things in the first place. They, like all others relied mostly on you having a good eye to start with. Nothing concrete.

Detection is the first step. Can't fix it if you don't know THAT it is broken, much less WHAT is broken. So, now you are wondering if here is where I let you in on my little secret. OK I'll tell you what it is.... the secret is that some see it/do it, and to my befuddlement others can't. Wish I had more...

The engineer inside is searching for the equation and the scientist for the method to facilitate reproduction. There must be a process we can implement to produce applications of a singular style and high level of usability.

I'm still looking for something concrete...