Showing posts with label Coding. Show all posts
Ease-of-Use SDKs Are Just Toys
Posted by Phillip Jackson in Coding, Craftsmanship, Duct Tape Developer, Self Training on 22 September 2010
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
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.
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 ToysIt'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.
No one is trained to do it
Posted by Phillip Jackson in Coding, Craftsmanship, Engineering, Self Training, Steve McConnell 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.
McConnell: Software Engineering, Not Computer Science
Posted by Phillip Jackson in Coding, Craftsmanship, Engineering, Self Training, Steve McConnell
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
Posted by Phillip Jackson in Coding, Craftsmanship, Duct Tape Developer, Joel Spolsky 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.