Software Development, Work Projects

Going where no QA has gone before!

As a developer having QA you can rely on is great! They are welcome friends helping us cultivate our precious software. But there are dark places which even a QA cannot shine a light. When your software has no interface, what can a QA do, but wish you luck? But what if there was a way for QAs to interact with otherwise UI-less software? Enter Cucumber, a tool that allows QA to shine a light in dark places.

I rediscovered Cucumber, while researching test automation frameworks. Cucumber is a framework for Behavioral Driven Development. After experimenting for a time, I realized Cucumber opens a whole realm of possibilities. Cucumber encourages the expression of program actions in the human tongue. With a proper translation mechanism, Cucumber could act as a mediator between QA and the UI-less software. 

Cucumber translates the human tongue into functions through the Gherkin language. For example, a tester would define a test case like this: 

Scenario: Messages are saved until the consumer arrives
Given the queues are empty
And I publish a message to the queue with ‘SomeDetails’
When Alice subscribes to the queue
Then Alice should receive a message with ‘SomeDetails’

It is fairly easy to understand the behavior that is being described in this scenario. Cucumber ties the keywords Given, When, and Then to functions which execute the described action using a Regex Match string. This can include free-hand parameters such as ‘SomeDetails’. 

Properly designed, the Givens and Whens can be setup to be repeatable and re-compose-able. Doing so allows the QA to describe more complex scenarios with different combinations of the same simple behaviors. As a result, once the initial steps are available, a QA could test to their hearts content with little developer support.

Cucumber improves the documentation of a product. Test document expected behaviors in a common tongue. This makes them available to all parts of the company.

But great care must be taken to ensure that the compose-able parts function precisely as described and without side-effects. Imperfections in the design or the aforementioned side-effects will destroy test-validity and erode trust in the test cases written using Cucumber.

Cucumber was designed to improve TDD, enabling members of a team to describe the function of a program in a human tongue. This same feature creates a tool for empowering QA. Given careful planning and design, you can compose a terse but flexible set of instructions. These allow a QA to test projects they could never touch before! By blending the skills of a developer and a QA, we can reap the best of all our talents. All it takes is an investment to allow our friend in QA to come with us!

Standard
Perspective, Software Development

For the love of the User

Software is for the user. It is not for the Software Engineers who develop it. In the end, software will succeed or fail to meet user needs. The user is the arbiter of software’s fate. Oddly though, many software developers tend to resent their users. The users are prone to strange behaviors. Sometimes they can even come across as whinny children to jaded developers. But we must do away with this flawed way of thinking. We must act as humble stewards, gentle of heart, and eager to please.

Users are the life blood of a software product. Without them, the product will fail. As a result their needs are paramount, and must be address to the best of our abilities. If this is the case, then why are developers so often frustrated by their users? Remember we are fluent in the machine tongue. Generally speaking, users aren’t. Sure they can use the machines, to a limited degree. But they don’t understand them like we do.

Imagine you are in a foreign country. The only way to get your work done is to cajole a lumbering beast into action for you. Without understanding the beast’s language, even simple tasks could be infuriating. Users who are less familiar with software might feel the same. Only remember that we specialize software to particular tasks. As a result users need to learn, remember and use a variety of these ‘beasts’ to get their work done. Also remember, they are being evaluated by their ability to get work done, using your software.

And so scared, frustrated, and feeling impotent, they turn to us. They wonder why their actions did not work. They ask for strange features or work-flows. All these feeling arise because they don’t understand their tools. Sure we could ‘educate them’. But if the way to use a tool is less than obvious, or they only use it seldom, then you can expect them to forget. Not to mention, you have to convince them to take the time to get trained, rather than working. Even we don’t feel comfortable trading training time for working time. So why should we ask that of them?

Two paths remain to us. We can tell the user’s they are wrong and constantly bicker with them, trying to explain the proper way. Or we can choose to listen. The way we thought was obvious is not. They need more help, because the grammar of machines is difficult. I would call this path ‘Stewardship’. We have to think of the code as belonging to the users, not to us. In so doing, it becomes clear what choices we need to make. If the code is for the user, then their needs overrule ours. If they aren’t fluent, we must may the software more approachable.

We are like gardeners. The land we tend is not our own, but still we make it bloom with brilliant flowers. We cherish the blossoms, and suffer when they are trodden upon. But the garden is not for us. Imagine if the gardener chased off the owner with a spade when he ask for a new row of lilies. The gardener would be marched off and a new one brought in to replace him. This is not an exact analogy, since users pick their software. They might just avoid a certain gardener altogether.

If instead, we are gentle and approachable, we could better tend our gardens. If no one ever walks our garden paths, then we put to waste all the love and beauty to garden contains. Software without users, despite its brilliant design, and delicious complexity, is dead. If we want vibrant, living software we must serve our users. We cannot lord our understanding over them, but must instead steward the code for them. With gentle hearts, we can learn their needs, and make the garden they need. In the process we may discover an even greater beauty.

Standard
Perspective

ROI of Training

What kind of investments do you make? Do you favor immediate returns on investment? Or do you favor guaranteed returns? How long are you willing to wait? Time spent in training or practice is equal to making an investment. Different methods or focuses produce different results.

Much of the training available in the software industry focuses on new frameworks. With a myriad to choose from, there is no shortage. There are many introductory courses. All encourage picking up the tool and applying it to basic problems. Yet these frameworks are subject to change. Two years down the line the framework will change. Sometimes in two years it can become obsolete. In other cases, it becomes an industry standard.

All in all, these skills degrade. Some of the degradation comes from market changes. Lack of practice also contributes to the decay. How often do you truly use that obscure array access format in language so-and-so? Rarely, for most of us. Yet there is a class of training and investments that are less likely to degrade: People skills.

People skills are usually presented in management or leadership courses. They are an investment class of their own. The opportunities to practice people skills are vastly more numerous. As a result they do not suffer as much ‘lack-of-practice’ degradation. Furthermore, people skills remain in demand for many higher level positions. Want to be a consultant? You need People skills. Want to start your own company? You’re gonna need people skills. But these skills are difficult to acquire. In fact, these skills are in high demand precisely because they are difficult to acquire.

People skills are also applicable across industries, if you ever wanted to move. The skills of a software developer carry over any industry we develop for. Much the same way, the core skills of a manager translate well across industries. As career capital, they pay large dividends.

The best investment for anyone strong depends on what they want from life? I enjoy the challenge and rewards of programming. But I am interested in the role of management, and in its unique challenges. With an eye to the future, people skills appear to be the best investment. The skills suffer less degradation with time, and have remained in demand over the long haul. What do you value in your investments? Do you want to expert in technologies? Or do you want to diversify? Hopefully this perspective provides another lens for reflections.

Standard
Perspective

Software Developers are Translators

What is a Software Developer? I know they ‘develop software’. But that is like saying water is wet. What is the fundamental action we train software Developers for? Could you use it to distinguish to excellent from the mediocre? I’d say you can. The fundamental task for Software developers is translation. Software Developers are in essence, translators.

Software Developers are individuals who can speak both to man and to machine. At a low level, they literally translate human sentences and ideas into instructions for computers. Ever used a poor translator app? Then you know proper translation takes some finesse. You have to understand the culture of the language you are translating to. You need to understand the idioms and the proper grammatical structure. Otherwise your translation won’t turn out well. It might sound like terrible high-school writing. Worse, it might be a hollow mechanical echo of the original work.

The difference between a ‘good’ developer and a mediocre one hinges on the mastery of the language. The good developer knows the right idiom to convey the fine details of a phrase, while the mediocre developer might be able to eventually explain the instruction. The good developer can instruct with elegance and in some cases even a flourish. This even extends to translating behaviors. In technical language this is the UX. A good developer accounts for the expectations and the wants of those using it. He elegantly handles the use case. The trouble comes when trying to quantify these differences. They are differences in quality rather than quantity. But that is for a different discussion.

A good developer also recognizes the short-comings of the medium. Some things can translate when in their original form, others need to be recast. The target language/culture may not be able to sustain the desired content. Vocal inflection is useful for in-person discussion. They do not translate well into text message. Instead they need to be recast to maintain their emphasis. Put in plain language, computers can only do so much. A good developer recognizes the limitations of the system. He then communicates these limits to the humans he is translating for.

In a proper environment, the software developer would act as a representative of the machine to man. The good developer would help him to understand the needs and abilities of the machine. At the same time, the developer would act as a representative of man to machine. He would ensure that behaviors would meet expectations of man. These two tasks would form a cycle. The developer brings the needs of man to the machine. Then he returns with the limitations and requirements of the machine. Over several cycles, and accommodations, we find a successful system. In spirit this cycle is like Agile software development, though without the extra trappings.

Now if a Software developer is a type of Translator, should we change how we measure them? We can or ought to borrow from the way the Translation business operates. Or adopt their performance measurements? A good software developer acts as a fluent translator between the worlds of man and of machine. Through clever use of language, they translate the desires and needs of men to the machines. And then they bring back the requirements and limitations of the machine. In a proper cycle, both can prosper from this feedback. The good software developer is like a good translator. He is aware of the idioms of his target language as well as the culture. Thus he can make an effective, compelling translation of the original.

Standard
Perspective

‘Code is read more often than it is written’

My Blog has moved! You can find my latest content at daniel.scheufler.io. Please continue reading here.

At first glance, this would seem an obvious statement. And it is in a way. When Python language creator Guido Van Rossum created Python, he did so with this thought in mind. As a result, the culture of Python is partly molded around “readability counts”.

The more I thought that statement, the more I realized the marvel it held. ‘Code is read more often than it is written’. If asked to choose between reading and writing, I would have said the same. And yet I realized now, that much of the code I have read, and some of the code I have written does not show this. I wondered, why did my behavior, and that of my peers, not match what I knew to be true? If we believed that code was read more often, they why is so much of our code so hard to read?

At the core, our behavior remains unchanged because this quote is only an observation. There is not imperative contained in it. Without the means of an imperative, the observation cannot turn into an action. Instead the reader would need to derive ‘Code ought to be easily read’ from ‘Code is read more often than it is written’. I trust most would be equal to the task, given a basic desire to optimize.

When I first discovered this, I did not pay it nearly enough attention. I went blithely on my way. Some time later, during the quiet of a vacation, the thought came storming back. I was left dumbfounded. How could I have not seen it earlier? I realize now, it was because I had not given my self enough time to think. With the lighter load during vacation, I was able to think, and so naturally the thought came.

This moment of serendipity also encouraged other considerations. Specifically, what other imperatives had I missed with casual observations? I quickly realized this is dark territory. It would be difficult to turn every observation into a possible imperative. Worse still, these observations might be biases, leading to bad imperatives. Or they might be too weak to lead to a meaningful imperative.

In all cases, the question remains, what have I missed? I believe, especially in software, that we are caught in a rush to develop, to implement, and to finish. As a result, we do not give ourselves time to ask, ‘Is this the best way?’ Business demands that we move with purpose, and that is a reasonable demand. But for the best results, we need time to consider if we go in a way that will deliver us to the goal we seek. I will continue to look for miss-able observations may turn out to change everything.

Addendum:

While drafting this article, two other examples of ‘observation leading to imperative’ appeared. The first was fictional, from Foundation and Earth by Isaac Asimov. In the book, the protagonist remarks with surprise at the neural interface to a computer. Instead of being an over-the-head affair, it was through the hands. His realization was that humans sense and interact with the world through their hands. I may revisit this in a later branch of this discussion on design.

The second example, sprouted from the first, specifically interaction and design. Recently the IoT movement has brought integration to our homes. In particular, the voice-interaction, such as Amazon’s Echo or Google Now. I observed that these devices extended a natural principle: ‘Humans use their voice to make their wishes known.’

Standard
Perspective, Software Development, Work Projects

Where’d my UX go?

Disclaimer: I am not the happy looking chap in the photo.

I was working on a personal project recently when a realization dawned on me. User Experience Design,also known as UX design, and software design collide more frequently. And not only in the User Interface layer.

Before I get too far, when I talk about UX, I am referring to the experience the user has while attempting to use the device or object, or code. I think this image does an excellent job of describing good UX concisely.

Link: http://i.imgur.com/9LqhOl3.jpg

It’s pretty easy to tell what UX is like with a Graphic User interface, or a GUI. After all, this is the part everyone touches. If a website is snappy and the layout makes sense, that is good UX. If it is clear how to do the operation you want, without needing to consult the magic talking paperclip, then it is a good UX. But it seems that once you go below the GUI layer, the lessons on good UX vanish.

I was working on a Fluent Testing API for python when I realized it. In version 1, I had all the functionality for this API bound up in a single class. Sure, it limited the import tree, and made it easy for me to develop. For version 2, I decided to pull the functions into separate classes. And while I was writing out some example cases, I realized that this simple code change resulted in an augmented User Experience!

You see, by pulling the various functions into different classes, I allowed the IDE to create better prompts. The better prompts now guide a user of my API through the proper pattern of using my API. Since there were fewer functions to choose from, it is now clearer how to proceed. The user no longer has to consult a lot of documentation. This is a simple example, but it did get me thinking.


In fact, one week prior, I added a Facade to one of my library at work. The Facade simplified interactions with my  Library. Now other software engineers could more readily use my library’s functionality. I am surprised that I didn’t think of it at the time, but APIs are a Software Engineer’s UI layer. As a result, they should be subject to a UX review!

I mentioned earlier that I have noticed that, on the whole, UX degrades as you leave the GUI layer. Two factors are responsible, in my opinion. First, the majority of UX review and work goes into the GUI layer. And this focus makes sense. The vast majority of software interaction is through such a layer. As an aside, finding a UX guy who can talk about UX and about API design can be difficult. I usually have a heck of a time getting time with them to review a GUI design with them!

The Second factor is a lack of discipline. I am not throwing stones here, the first version of my Testing API is example of such a lack! I collected all the functionality in a single class because it was easier for me!  I wanted to get the functionality together and to reduce the import tree. In hindsight this is a silly reason. And yet, it was enough to change my behavior.

So now that I’ve seen the problem, what can I do? Well, I noticed the improvements made in the UX for version 2 by writing up some examples. That is to say, I used it. This is a good start, bu submitting it to user testing would be a better step. After all, as the design I was intimately familiar with the inner workings and the proper usage of the tool. But a fresh user wouldn’t be. And if there is anything I have learned developing software: the user never does exactly what you expect them to.

Besides more user testing, some cross-functional education might help. This recent epiphany put me in mind of a tech talk that I hadn’t finished. You can find the youtube video here. I am hoping that revisiting the principles from the talk will continue to improve my designs!

Standard
Perspective, Work Projects

So tell me, Why do we pay you?

 

 

So imagine this: you are sitting at your desk at work. When a mid-level manager strolls up and asks you the following: “Why are we paying you to do what you do?” Could you answer him? Would he understand the value of keeping you if you did?

Recently, I had a chance at work to answer this exact question. Thankfully, the situation was much more relaxed. You see a project that I am the technical lead of was awarded a Project Manager. To me this means that the business thinks that what I am doing is valuable. Valuable enough to pay someone to make sure that it is well staffed, organized and properly directed. I am pleased with the direction we are going.

But as one might expect, the Project Manager was not a software engineer. So naturally explaining the value of the project in software terms wouldn’t help. The make matters more complicated, the project is not customer facing. It is in fact a business solution, helping to tie many other services together.

Since this project had been without a Project Manager for a while, we had never completely translated the value of the project into business terms. As a result our first meeting with the PM experienced a little bit of a disconnect. We spoke about the value the software provided to other software applications. But our PM had some trouble translating that into meaningful terms for herself.

So following the meeting, I took it upon myself to attempt a business translation. I took what I knew about the project and its value and translated that roughly into business terms. I certainly did not do a perfect job. But I believe that some benefit may come from discussing what I have learned over the years and was able to apply to this project.

As I see it, Business Value comes down to just one thing: More Money. But there are two ways to achieve this end. Either you make them money, or your save them money. If you can translate your work into one of these two parts you can usually make a business case for it.

Our project was created to simplify the process of connecting many apps. The project would make it easier to maintain, and easier to extend the connections between application. It would also support new feature implementation. Moreover, since the new system is simpler, it reduces the likelihood of incorrect actions by our system. So how does one translate this into saving or earning more money?

If the project make it easier to maintain a system, then it reduces the man-hours spent on maintenance, right? If you save man-hours, then you are saving money right? If you want to go the extra mile, provide an estimate of how many man-hours it saves. Then multiply those hours by the average software engineer hourly rate. This provides a number of dollars that your project can save the business!

Since software projects often provide a benefit for many years; try to provide information about saving during a single year. So if I save 8 man-hours a month, I save the company 96 man-hours or 3600$ per year (assuming a salary of 75K$).

To take the example a step further, I can also factor in the cost of my work on the project. Let us say that it will take me 42 man-hours ( or roughly 1 week of work) to complete this feature. Then it will cost the company 1575$ to produce. The result is a net savings of 2025$!

Going back to my project, since it makes it easier to extend, the cost to implement it will be rather low. If you can quantify how much time it will take to implement your solution, you can provide a more accurate estimate to the business.

The project is designed to make it easier to add new features to our system. This means that it reduces development cost. Additionally, it means that the new feature can make it to the market faster. Do not under-estimate this! Faster Time-to-Market can provide your company a competitive edge.  The edge comes from either by being the first to provide a particular functionality, or by begin able to under-bid competitors. While it can be difficult to provide exact value numbers on this, you can highlight the man-hours saved in development. I find it easiest to understand by providing a comparison to the current process.

To provide a good estimate, I recommend using a current project. Comment on the time it took to implement the part of the feature related to the new project. Then compare it to the time it might have taken using the new project. This provides a tangible example of the value your project creates.

Finally, my project simplifies the logic of linking multiple services. This simplification reduces the risk of errors. To put a value on this, you need the time saved. Start with the current time spend debugging. Then estimate the how much your project would save, based the project’s implementation.  My project simplifies by pushing the logic into a more appropriate context. It also allows the using services to dictate the communications they wish to react to. As a result nearly all the current bugs could be eliminated. Not 100% of course, but a sizable chunk, perhaps 70-85%. Using this estimate, you can translate the man-hours saved into dollar value as before.

Translating from software value into Business value isn’t always easy. But it is doable. Further, it is quite approachable if you have the right mindset. How am I saving the company money, or how am I earning them more money? Once you have these answers, you can begin the translation into business terms.

To be sure, the estimates you provide when you first start will be a bit optimistic. But with time, practice and experience, they can become more realistic. I am certain that the estimates I provided to my PM were lacking in some respects. But something is better than nothing! And I got to learn a valuable lesson in translation!

If you have a project to translate, I’d be happy to discuss! If you have any pointers, I would appreciate your suggestions! Just send me a message! Good luck and Happy hunting!

Standard
Software Development, tools

Dev Tool: Atom – Revisited

Atom is Github’s hackable text editor. I was introduced to it by a friend in college. Since then I have used it for various tinkering projects in Python, and an Arduino project with a couple of friends. Atom is awesome!

Atom doesn’t ship with support for everything, which is alright. But what makes Atom great, is that it is extensible! It has a rich marketplace of published extensions offering support from Python to C, and Json to Yaml. I discussed some of the packages that I used to support both python and Arduino in my previous post.

Lately, I have been using Atom as my go-to REPL environment. Now, there are other tools like repl.it, which are great for rapid feedback tinkering. However, I always feel … iffy about online solutions. They can be great, but if the power is out, or the internet is down, or worse slow… well there go the advantages.

But last week, I started to notice that my instance of Atom was starting a bit slow. Mind you it was just a few seconds, but it was noticeable. So I started hunting. After a while I found that Atom ships with a plug in called Timecop. Timecop tracks performance times of the modules that you have installed and active. It tracks the load time, the init time as well as other associated metrics.

As I started snooping I found that several of my modules were really slowing me down. For example, a bit more than a half second was lost to Omnisharp, which I had loaded to support C# tinkering. Additionally the C Language Linter Library also ate considerable time.

C and C# are not the fastest REPL languages for me. As a result, I decided to pare down the modules that I had supporting them. Now don’t get me wrong, I love C# for business development! I just feel that it can be cumbersome for REPL workflows. So, I uninstalled some of my modules, like Omnisharp. But for C, I just deactivated them. This is because C is often used for Robotics and Arduino Associated applications.  Since the modules were still installed, I could turn them back on. Thus the features can be used without incurring the start-up cost every time I launched Atom.

All in all, this was an interesting exercise, and I thought that others might benefit from hearing about it. I am rather pleased with the results. And after gaining this experience, I am think that my next challenge will be to write a plug-in or module myself! I recently found this tutorial that I think will help.

As always thanks for your time! If you found this post interesting, I would encourage you to check out my personal blog. I have several posts on Development Tools that I think you might like!

This was originally posted on LinkedIn with the Title Dev Tool: Atom. Since that was the original post’s title, I have changed it. Further, this post originally refered to the plugin as Timeit. I discovered later that was incorrect. I have applied this correction here.

Standard
Journeyman's Digest

Journeyman’s Digest 05

Issue 05

This Issue’s Highlight

Plasma Air Control – It would appear that the next advance in flight technology may be on the horizon. By manipulating the placement of plasma along a wing’s edge, a team of researchers have fine-tuned the flow of air over the wing. This leads to improved efficiency and several other very promising possibilities!

How long can you stop the cheaters? Apparently, 4 days… – Back in August, Niantec put in place some anti-cheat measures in Pokemon Go. This was to stop cheaters from running various bots that would rapidly level you character for you. In the end, this change really only stopped the bot creators for about 4 days. This Ars Technica article discusses more of the happening related to combating the anti-cheating fix.

The Goods

A new component for Data Storage – Researches have learned the basics for controlling a new component  as a storage media. These Bose-Einstein Condensates, are an amalgam of particles, which can carry information in both the polarity of their photon, and in the spin of their exiton. This new technology could provide a bridge between voltage based and optical circuitry.

Additional controllable properties of Black Phosphorus found  – Black Phosphorous has shown some potential as the next Silicon. Recently some researches with Case Western have discovered another controllable property of Black Phosphorous which may unlock additional potential of this martial!

Vehicle Security Hack  – As it turns out that little key-dangle remote for your Volkwagen might not be very secure. With some minor snooping on a different remote, an Arduino could be used to spoof the signals necessary to cause the Volkwagen to open. Apparently, there was only a few ‘keys’ used by these remotes.

An anti-pattern for Stand-ups – Don’t get me wrong, a stand-up, done right can be great. It keeps everyone up-to-date, and in the know. If people are engaged, then the knowledge necessary to solve a road-block can easily be identified. If this happens, the stand-up, far from interrupting work, actually improves the speed at which work can be done! But even a good tool, if used improperly can be more a burden. This post discusses some of the way a stand-up can go awry.

This Issue’s Curiosity

A Discussion of some bad habits science has gotten into – Science is great! It’s how we know what we know, and more over its how we can learn! But even such a technology as the scientific method has flaws. Namely, humans are the ones that have to execute it. As a result, this system can come down with some unfortunate habits. This post offers some insight on a few of these, and is worth a read.

Emojis: The Growing-pains of a language – Emojis, a language? Actually, if you think about it, Emojis are basically a newly formed written language. But as with all growing languages, new symbols and their means mean that not everyone will use the same symbols for the same meaning. To complicate matters, since Emojis are rather technology based, the emojis available with Android and iPhone are diverging. This article offer some interesting perspective on that branching.

Standard
Journeyman's Digest

Journeyman’s Digest 04

Issue 04

This Issue’s Highlight

A DIY approach to internet – So everyone knows that the ISPs don’t provide the best of services. So, one gent in Spain got fed up with waiting for them to run internet to his house, so he did it himself, by modifying commercially available equipment. After a while, his neighbors asked him to do the same for them, and he set up a small network. This network grew. And now he has an organization helping him to roll this out over more of the country, and helping him negotiate more service based deals with providers. These new providers instead offer tech-support, installations, an maintenance, rather than owning the wire or the data going through. It is a new and interesting model. I wonder if it will ever be able to come to the US.

On How to disagree – The author discusses a rather contentious issue, namely abortion, but decides to take a different approach. He may disagree, but he realizes that the only way to help anyone towards your opinion, is to treat them with respect, and understand that we all have stories. This article made me pause. No matter if you agree with his stance or disagree, the suggestion for how to disagree in a more constructive way is powerful!

The Goods

Netflix’s open-source Traffic intuition tool – So Netflix, has updated it’s open source traffic-intuition tool. This tool is apparently responsible for balancing the load of the Netflix servers, and keeping data speeds at reasonable levels. For those of us in Tech, it is an interesting topic, and this project might hold some insights.

China builds a traffic straddling bus! – So that futuristic idea of a bus that simply rides over traffic? Yeah, a company in China actually built it, and did a test.

… but maybe it isn’t as impressive as originally thought. – Don’t get your hopes up too much though. Apparently, the city official’s didn’t even know the test was happening. Further, as one might expect for an initial test, the traffic conditions were carefully controlled, and the test course was not very long. However the most concerning news, is that the bus only supports traffic up to 10 feet off the road… the city’s limit is 20 feet, which might mean that the bus cannot remain street legal, and still dodge the larger trucks.

Thinking in systems, a summary – The author of this post, provides his summary of several systems he has found useful for thought. I found it an interesting compilation, and thought you all might find something useful in it as well.

Product Development Cycle Fundamentals – As the title suggests, it is a discussion of the fundamental of the cycle of product development. For anyone familiar with Agile, these will be familiar, but I particularly appreciate the authors remarks on the need for a measurement of success. I have experience attempts at development without such markers. These were difficult to say the least.

How to start a 1500USD business using a public API in 4 months – Another article from a small-business entrepreneur. This time, the authors discussion revolve around finding the niche for the business, as well as learning to adjust to the inconsistent stream of income. Over all, I found it an informative read.

 

This Issue’s Curiosity

Some start-ups trying to take the pain out of car buying – So someone finally decided to try to make a better car-buying experience. Anyone whose bought a used car knows the pain and the toil that goes into finally getting the car out of the dealer’s lot. This article discusses two companies, with two slightly different approaches, who are trying to make that process less arduous and frustrating.

Fears that Snowden may be dead – By now, anyone who follows the tech-related news closely, should have heard of this. Snowden’s twitter account posted what looked like a hexadecimal cryptographic key. This spurred speculation that it is the key for archives he has shared with various news sources, and that if the key was shared, it might mean his detention or death. The news of this is troubling in my opinion. But I found the discussions surrounding the event interesting.

Standard